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Evaluation 


The  Automated  Air  Information  Production  System  (AAIPS)  is  being  integrated 
into  the  production  environment  of  the  Defense  Mapping  Agency  Aerospace  Center's 
Aeronautical  Information  Department  (DMAAC/AD)  in  a  phased  manner.  The  first 
phase  involved  a  total  system  design  with  implementation  of  a  pilot  system  to  prove 
system  design  concepts  and  operational  software.  Successful  testing  of  the  pilot  system 
showed  that  AAIPS  would  be  able  to  meet  the  strict  schedules  imposed  on  production 
of  Flight  Information  Publications. 

During  the  second  phase  of  the  contract,  the  pilot  system  was  analyzed  to  determine 
its  shortcomings  and  the  original  design  plan  was  revised  to  keep  the  system  up  to 
the  state-of-the-art  and  to  improve  its  production  capabilities.  The  resulting  system 
provides  the  DMAAC/Aeronautical  Department  with  a  very  effective  up-to-date  production 
system  capable  of  being  easily  enhanced  to  meet  future  production  requirements. 
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JOHN  R.  BAUMANN 
Project  Engineer 


SECTION  1.  INTRODUCTION 


1.1  GENERAL 


This  is  the  final  Technical  Report,  Automated  Air  Information 
Production  System  (AAIPS) ,  Rome  Air  Development  Center  Contract  Number 
F30602-77-C-0065 .  This  report  is  submitted  as  required  by  Contract 
CDRL  Item  001  Attachment  6  and  has  been  prepared  in  accordance  with 
Data  Item  Description  DI-S-3591A/M,  MIL-STD-847A,  and  other  pertinent 
directives . 


1.1.1  Background 

The  Aeronautical  Information  Department  (AD)  of  the  Defense 
Mapping  Agency  Aerospace  Center  (DMAAC)  is  responsible  for  the 
acquisition,  maintenance  evaluation,  and  exploitation  of  aero¬ 
nautical  information  to  support  Defense  Mapping  Agency  (DMA)  Aero¬ 
space  Charts  and  Flight  Information  Publications  (FLIPS)  distributed 
worldwide.  This  information  is  provided  to  the  Department  of  Defense 
(DoD)  and  other  agencies  and  authorized  users  for  flight  operations 
and  logistical  planning  purposes. 

The  major  AD  production  programs  include: 

a.  DoD  Flight  Information  Publications  (FLIPS) ; 

b.  Navigation/Planning  and  Special  Purpose  Charts; 

c.  Special  Products;  and 

d.  Automated  Air  Facility  Information  File  (AAFIF) . 

1.1.2  Flight  Information  Publications 

FLIPS  produced  are  associated  with  Alaska,  Pacific  Australasia 
Anaractica,  Canada  North  Atlantic,  United  States,  Caribbean  South 
America,  Europe  North  Africa  Middle  East,  and  Africa.  The  general 
types  of  FLIPS  are: 

a.  planning  documents; 

b.  en route  charts  and  supplements;  and 

c.  terminal  procedures. 
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1.1. 2.1 


Planning  Documents 


The  eight  separate  planning  documents  consist  of  pre-flight 
planning  information  such  as  standard  terms/abbreviations,  meteor¬ 
ological  data,  pilot  procedures,  special  use  air  space,  parachute 
jumping  areas,  and  military  training  routes. 

Collectively  the  planning  documents  consist  of  about  50,000  lines 
of  text;  over  5  million  characters  of  information.  They  undergo  about 
3,500  update  transactions  (representing  37,500  text  line  changes)  per 
year. 

1.1. 2. 2  Enroute  Charts  and  Supplements 

These  publications  consist  of  91  flight  chart  and  six  textual 
supplements;  they  typically  contain  such  information  as  airway  system/ 
special  use  air  space,  aerodrome  data,  and  navigational  facilities. 
Objectively,  the  enroute  supplements  contain  140,000  lines  of  text; 
almost  11  million  characters  of  information,  and  undergo  nearly  45,000 
update  transactions  representing  over  62,000  lines  of  text  changes. 

The  enroute  charts,  produced  in  large  graphic  format,  typically  re¬ 
quire  over  800  changes  per  year.  Contents  of  the  publications  vary. 

Enroute  Supplements  for  Foreign  Areas  contain  sketches  of  selected 
aerodromes  and  heliports  as  well  as  text.  The  IFR  Enroute  Supplement 
US  is  essentially  textual  with  no  aerodrome  sketches.  The  VFR  Sup¬ 
plement  US  contains  aerodrome  sketches  with  supporting  text  of  military 
and  general  aviation  aerodromes. 

1.1. 2. 3  Terminal  Procedures 


The  publications  are  standardized  graphics  illustrating  predeter¬ 
mined  maneuvers  for  runway  approaches  and  landings  and  instrument 
meteorological  conditions.  There  are  three  basic  types  of  Terminal 
Procedures. 

There  are  approximately  2,900  Instrument  Approach  Procedures  (IAPs) 
which  undergo  over  4,500  changes  annually.  The  near  1,350  Standard 
Instrument  Departures  (SIDs)  are  maintained  with  about  1,500  changes 
per  year.  The  approximately  550  Terminal  Charts  are  supported  by  over 
1,600  updates  made  each  year. 

1.1. 2.4  FLIP  Production  Cycles 

The  FLIP  annual  production  is  broken  down  into  five  (5)  categories; 
the  semi-annual,  84-112  days,  56  days,  28-56  days,  and  monthly  revisions. 
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1.1.3  Navigation/PI anninq/Special  Purpose  Charts 


These  charts  require  selected  overprint  data  (portrayed  by  symbol¬ 
ization  with  textual  description)  regarding  such  aeronautical  information 
as  airfields,  electronic  navigation  aids,  and  special-use  air  space. 

The  annual  workload  for  the  aeronautical  overprints  is  nearly  1000 
compilations/revisions  per  year.  The  types  of  charts  and  their  associated 


product 

scales  are  as  follows: 

a. 

Tactical  Pilotage  Chart 

1 : 50r , u00 ; 

b. 

Operational  Navigation  Chart 

1 : 1 , 000 , 000 ; 

c . 

Jet  Navigation  Chart 

1:2,000,000;  and 

d. 

Global  Navigation/Planning  Chart 

1:5,000,000. 

1 . 1 .4  Aeronautical  Information  Special  Products 

The  three  types  of  special  products  are: 

a.  Aeronautical  Video  Mapping; 

b.  Tactical  Situation  Displays;  and 

c.  Airfield  Diagrams. 

1.1.5  Automated  Air  Facilities  Information  File  (AAFIF) 

AAFIF  is  an  automated  file  of  evaluated  information  pertaining 
to  all  foreign  free  world  airways.  AAFIF  currently  maintains  approx¬ 
imately  45,000  airfield  records;  daily  information  updates  number 
about  2,000.  The  over  400  million  characters  comprising  AAFIF  reside 
on  21  reels  of  magnetic  tape.  AAFIF  informational  content  is  categor¬ 
ized  as  follows: 

a.  General  Identification  and  Description; 

b.  Operational  Users ; 

c.  Navigation  Aids  and  Communications ; 

d.  Airfield  Description; 

e.  Maintenance  and  Servicing; 


I'l 
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f.  Special  Purpose  Equipment  Base  Services;  and 


g.  Transportation/ Weather . 

Outputs  derived  from  AAFIF  source  information  are  recorded  on 
magnetic  tape  or  printed.  Approximately  90  different  products  con¬ 
stitute  the  scheduled  production;  roughly  one-third  in  digital  tape 
form  and  the  remainder  as  hardcopy  printed  reports.  Scheduled  product 
users  are: 

a.  Defense  Intelligence  Agency  (DIA) ; 

b.  World  Wide  Military  Command  and  Control  System  (WWMCCS) ;  and 

c.  Other  US  Government  Agencies. 

Yearly  production  of  magnetic  tapes  averages  800;  the  weekly 
average  is  15  with  weekly  peak  loads  as  high  as  100.  Average  annual 
volume  of  hardcopy  printed  material  is  700,000  pages;  the  weekly 
average  is  13,000  with  typical  weekly  peak  loads  amounting  to  80,000. 


1.2  PURPOSE 


The  Automated  Air  Information  Production  System  (AAIPS)  has  been 
implemented  by  Synectics  Corporation  under  contract  to  Rome  Air 
Development  Center  ( RADC)  for  the  Defense  Mapping  Agency  Aerospace 
Center  (DMAAC) .  The  scope  of  this  effort  encompassed  the  analysis, 
design,  specification,  implementation,  and  test  and  evaluation  of  all 
hardware  and  software  components  of  the  various  subsystems  of  AAIPS. 

This  is  the  final  report  marking  the  completion  of  all  work 
performed  during  Phase  II  of  the  AAIPS  system  development  program. 


1.3  PHASE  I  SUMMARY 


Phase  I  of  the  AAIPS  Program  required  the  development  of  a  base¬ 
line  design  for  the  total  system  and  the  implementation  of  a  PILOT 
system. 

The  scope  of  the  Phase  I  effort  encompassed  the  analysis,  design, 
and  specification  of  all  hardware  and  software  components  comprising 
a  three  subsystem  AAIPS  concept.  The  PILOT  system  development  in¬ 
cluded  the  acquisition  and  integration  of  hardware  components  and  all 
custom  software  necessary  tci  successfully  demonstrate  the  capability 
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to  manage  and  process  l/15th  of  the  normal  FLIP/AAFIF  workflow.  This 
level  of  system  performance  constituted  the  major  evaluation  criteria 
for  determination  of  whether  to  pursue  the  total  system  development 
during  Phase  II  of  the  AAIPS  program. 

The  Phase  I  effort  also  called  for  a  complete  redesign  of  the 
Automated  Air  Facilities  Information  File  (AAFIF)  to  eliminate  redun¬ 
dancy  and  wasted  storage  capacity. 

The  AAIPS  system  functional  configuration  was  comprised  of  three 
subsystems  known  as  the  Publishing  Subsystem,  the  Charting  Subsystem, 
and  the  Air  Facilities  Subsystem.  Collectively  these  subsystems  ac¬ 
complish  the  automated  production  workload  of  all  Flight  Information 
Publications  (FLIPs)  and  the  Automated  Air  Facilities  Information  File 
(AAFIF)  as  described  in  Section  2  of  this  report. 

Each  subsystem  outputs  to  a  device  associated  with  the  Charting 
Subsystem  which,  in  turn,  is  capable  of  supporting  the  creation  of 
composite  ready-for-reproduction  film  negatives  using  existing  produc¬ 
tion  equipment.  The  subsystems  provide  an  extensive  machine-editing 
capability  for  data  entry  and  revision. 

The  principal  purpose  of  the  AAIPS  is  to  reduce  the  labor  required 
(by  manual  methods)  for  the  revision  and  republication  of  information 
critical  to  flight  operations  and  logistical  planning,  in  view  of  the 
anticipated  growth  of  both  the  types  and  volumes  of  information.  A 
by-product  of  that  labor  reduction  io  the  improvement  of  response  time 
between  receipt  of  changes  to  air  navigation/air  facilities  data  and 
the  dissemination  of  new  data  to  end  users. 

The  test  and  acceptance  of  the  PILOT  AAIPS  required  the  develop¬ 
ment  of  a  comprehensive  test  plan,  which  provided  the  guidelines  for 
the  achievement  of  the  system  goals  and  objectives  traceable  to  the 
original  statement  of  work  (SOW) .  The  procedures  for  testing  ensured 
that  all  requirements  would  be  demonstrated  and  sufficient  data  would 
be  collected  for  reasonable  evaluation.  Verification  of  the  original 
total  system  design  and  identification  of  necessary  design  modifications 
were  the  implicit  results  of  the  test  and  evaluation. 

The  test  objectives  for  each  AAIPS  subsystem  were  to  (1)  demonstrate 
that  hardware/software  and  firmware  capabilities  supplied  by  vendors 
performed  correctly  and  met  the  SOW  specifications,  (2)  all  subsystem 
functions  performed  in  a  manner  such  that  the  results  and  procedures 
matched  or  exceeded  the  SOW  requirements,  and  (3)  the  functions  and 
inter-subsystem  processes  could  execute  properly  and  perform  satis¬ 
factorily  with  the  l/15th  data  volume.  Tests  for  each  subsystem  were 
either  designed  for  inspection  of  operational  or  non-operational  hardware 
characteristics;  functional  performance  of  hardware,  software,  and 
operational  procedures;  and  volume  throughput  performance. 
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The  PILOT  AAIPS  as  developed,  implemented,  and  tested  at  the 
Defense  Mapping  Agency  Aerospace  Center  (DMAAC)  Aeronautical  Information 
Department  (AD)  successfully  met  the  performance  requirements  and  was 
accepted.  Based  on  the  evaluation  of  the  test  and  acceptance  results 
the  following  conclusions  were  drawn  from  the  Phase  I  PILOT  system 
development  experience. 

a.  The  concept  of  independent  subsystems  with 
independent  product-oriented  data  bases 
proved  to  be  very  practical  and  efficient 
in  supporting  production  activity. 

b.  The  products  derived  from  the  pilot  data 
bases  met  or  exceeded  the  product  quality 
specifications  used  at  the  Aeronautical 
Department . 

c.  The  maintenance  of  the  product  data  bases  by 
means  of  the  on-line  revision  functions  developed 
for  the  PILOT  subsystem  proved  to  be  much  more 
efficient  than  anticipated. 

d.  The  operational  procedures  that  were  iteratively 
refined  throughout  Phase  I  successfully  supported 
system  throughput,  but  improvements  in  this  area 
would  be  extremely  important  to  assure  successful 
total  integration  of  AAIPS  into  the  AD  environment 
during  the  Phase  II  effort. 

e.  The  hardware  selected  proved  to  be  responsive  to  the 
FLIP  production  requirements  and  was  well-received 
by  AD  personnel  who  had  hands-on  experience  during 
the  pilot  data  base  creation  and  test  period.  All 
hardware  was  of f-the-shelf  and  met  or  exceeded  the 
reliability  and  maintainability  requirements  in  the 
SOW. 


The  AAIPS  PILOT  system  was  clearly  a  success.  However,  definite 
items  for  improvement  during  Phase  II  were  detected  from  evaluation  of 
the  test  results.  These  items  were  subsequently  included  in  the  Phase 
II  development  plan. 


1.4  REPORT  ORGANIZATION 


This  report  is  self-contained  in  one  volume.  It  encompasses  the 
AAIPS  System  Overview-Phase  II,  Training,  Test  and  Evaluation,  and 
Conclusions  and  Recommendations. 


SECTION  2.  AAIPS  SYSTEM  OVERVIEW 


2.1  OVERALL  REQUIREMENTS/CAPABILITIES 


The  AAIPS  system  involves  a  functional  configuration  comprised 
of  three  subsystems  known  as  the  Publishing  subsystem,  the  Air  Facility 
subsystem,  and  the  Charting  subsystem.  These  subsystems  accomplish  the 
automated  production  workload  of  all  Flight  Information  Products  (FLIPs) 
and  the  Automated  Air  Facilities  Information  File  ( AAFIF)  as  described 
in  Section  1  of  this  report  (Figure  2-1) . 

The  principal  purpose  of  all  three  subsystems  of  AAIPS  is  the 
reduction  of  the  labor  required  (by  manual  methods)  for  the  revision 
and  republication  of  information  critical  to  flight  operations  and 
logistical  planning,  in  view  of  the  anticipated  growth  of  both  types 
and  volumes  of  information.  A  by-product  of  that  reduction  of  labor 
is  the  improvement  of  response  time  between  receipt  of  changes  to  air 
navigation/air  facilities  data  and  the  dissemination  of  the  new  data 
to  all  users. 

There  are  eight  overall  system  requirements.  Each  subsystem 
outputs  to  a  device  associated  with  the  Charting  Subsystem  which, 
in  turn,  is  capable  of  supporting  the  creation  of  composite  ready- for- 
production  film  negatives  using  existing  production  eauipment.  The 
subsystems  provide  an  extensive  machine-editing  capability  at  the  time 
and  place  of  data  entry  to  allow  for  operator  notification  of  invalid 
data  rejection.  A  restart  capability  which  protects  aqainst  data  loss 
and  allows  the  restart  of  all  jobs  is  also  provided  on  each  subsystem. 
The  subsystems  accept  and  output  codified  data  in  ASCII  code. 

The  System  Security  requirements  are  provided  as  explained  below. 
Remote  terminal  users  are  required  to  prove  their  authorizations  before 
obtaining  access  to  the  system.  The  supervisory  console  restricts 
access  with  its  disabling/enabling  control  over  remote  terminals. 
Irregular  log-on  procedures  resulting  in  access  denial  are  automatically 
accounted  for  and  recorded.  Appropriate  security  markings  are  appended 
to  all  hardcopy  reports  and  softcopy  displays  regarding  classified 
information. 


2.2  OPERATIONAL  ENVIRONMENT 


The  AAIPS  system  operational  environment  manifests  itself  in  three 
tangible  perspectives:  operational  procedures;  hardware  environment; 
and  personnel  functions.  The  overall  functional  framework  implemented 
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for  the  AAIPS  is  integrated  within  the  AD  environment  as  illustrated  in 
Figure  2-2.  The  Automation  Division  assumes  the  responsibility  for 
the  management  of  the  AAIPS  production  environment. 


2.2.1  Operational  Procedures 

The  operational  procedures  within  the  Aeronautical  Department  have 
undergone  several  changes  with  the  addition  of  the  Charting,  Air  Facilities 
and  Publishing  subsystems.  These  changes  are  necessary  to  provide  for 
a  smooth  integration  of  the  AAIPS  into  the  current  organizational  struc¬ 
ture.  The  details  of  these  procedures  are  listed  in  subsequent  sections 
of  this  report.  It  is  projected  that  the  operational  procedures  will 
be  refined,  on  a  continual  basis,  at  some  point  where  they  are  deemed 
optimum. 


2.2.2  Hardware 

The  AAIPS  concept  is  a  three  subsystem  concept.  Each  subsystem 
is  basically  independent;  therefore  only  hardware  compatibility  not 
dependency  is  required. 

The  Air  Facilities  subsystem  hardware  configuration  (reference 
Figure  2-3)  is  comprised  of  a  Data  General  Corporation  ECLIPSE  M-600 
processor  with  256K  words  of  MOS/ERCC  memory,  8-192  Mbyte  disk  drives 
supported  by  2  disk  subsystem  controllers,  a  2  Mbyte  fixed  head  disk 
and  controller,  a  16  asynchronous  line  multiplexor,  2-9  track  75  ips 
800/1600  bpi  magnetic  tape  drives  and  controller,  1-9  track  75  ips 
800  bpi  magnetic  tape  drive  and  controller,  a  7  track  75  ips  800  bpi 
magnetic  tape  slave  drive,  1-600  1pm  line  printer  subsystem,  1-60  cps 
Dasher  printer /key board,  1  Decision  Data  Model  8010  interpreting 
data  recorder  and  controller  capable  of  punching  75  cpm  and  reading 
200  cpm,  16  Datagraphix  Model  132B  Alphanumeric  CRT  terminals,  2 
Gandalf  Data  Inc.  Model  LDS  250/3  56  Kbps  synchronous  short  haul  modems, 
2  General  Data  Comm  Industries  TDM-1205  time  division  multiplexors, 
and  2  Government  furnished  KG-34  encrypt/decrypt  units  and  Mosler  safes. 

The  Publishing  subsystem  hardware  configuration  (reference 
Figure  2-4)  comprised  of  a  Data  General  Corporation  ECLIPSE  C-330 
processor  with  128K  words  of  core  memory,  a  4  line  asynchronous  line 
multiplexor,  a  436  1pm  (upper  and  lower  case)  lineprinter,  1-192  Mbyte 
disk  subsystem  (controller  and  drive) ,  1-9  track  45  ips  1600  bpi 
magnetic  tape  drive  and  controller,  1-9  track  75  ips  800/1600  bpi 
magnetic  tape  drive  and  controller,  2  Datagraphix  Model  132-A  CRT 
display  terminals  with  special  characters,  and  2  Informer  Model  V301 
CRT  monitors  and  controllers. 
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Figure  2-4.  Publishing  Subsystem  Hardware  Configuration 


The  Charting  Subsystem  hardware  conf iguration  (reference  Figure  2-5) 
is  a  dual  workstation  concept  supported  by  two  Data  General  Corporation 
ECLIPSE  S-230  processors  each  with  80K  words  of  core  memory.  Associated 
with  each  ECLIPSE  S-230  processor  is  a  192  Mbyte  disk  drive  and  controller, 
1  Datagraphix  Model  132B  CRT  display  terminal  with  special  characters, 

2-60  cps  Dasher  terminal  printer/keyboards,  2  Textronix  4014-1  graphic 
storage  CRT  displays,  1  Textronix  4631  hardcopy  unit  multiplexed  to  the 
two  graphic  CRTS,  and  2  Data  Automation  Corporation  Absolute  digitizers 
with  60"  X  42"  active  table  surface  area  and  16  key  free-moving  cursor. 
Associated  with  one  S-230  processor  are  2-9  track  75  ips  800  bpi  magnetic 
tape  drives  and  controller.  The  other  S-230  processor  has  2  9  track  75  ips 
800/1600  bpi  magnetic  tape  drives  and  controller. 

The  Charting  subsystem  output  device  (reference  Figure  2-6)  is  an 
Image  Graphics,  Inc.  AAIPS  Cartographic  Series  2000  Electron  Beam 
Recorder  (EBR) .  The  EBR  is  supported  by  a  PDP-11/34T  processor  with 
64K  words  of  core  memory,  2 . 5M  words  of  removable  RK05  disk  drives, 

1-9  track  800/1600  bpi  magnetic  tape  drive  and  controller,  1  TF.KTRONIX- 
619  graphic  CRT  monitor,  and  a  symbol/vector  generator. 

2.2.3 _ Personnel 

Some  personnel  changes  have  taken  place  in  the  production  environ¬ 
ment.  The  extent  of  change  and  functional  realignment  for  the  AAIPS 
production  environment  will  not  change  the  current  lines  of  responsi¬ 
bility  and  authority  within  the  AD  organization.  The  ultimate  source 
of  authority  and  responsibility  over  the  correctness  of  the  FLIP 
products  and  accuracy  of  the  AAFIF  information  rests  entirely  with 
the  Aeronautical  Information  Specialist  in  AD. 

2.3  SUBSYSTEM  SUMMARY 


The  principal  purpose  of  all  three  subsystems  of  AAIPS  is  the 
reduction  of  the  labor  required  (by  manual  methods)  for  the  revision 
and  republication  of  information  critical  to  flight  operations  and 
logistical  planning,  in  view  of  the  anticipated  growth  of  both  types 
of  volumes  of  information.  A  by-product  of  that  reduction  of  labor 
is  the  improvement  of  response  time  between  receipt  of  changes  to 
air  navigation/air  facilities  data  and  the  dissemination  of  the  new 
data  to  all  users. 


I  ZING  STATION 


Figure  2-5.  Charting  Subsystem  Hardware  Configuration 


The  purpose  of  the  DMAAC  Publishing  Subsystem  is  to  permit  the 
publications  to  be  produced  on  modern  electronic  equipment,  extend  the 
power  and  flexibility  of  digital  manipulation  to  the  updating  and 
reformatting  of  the  publications,  and  reduce  the  manpower  required  to 
produce  the  publications. 

The  DMAAC  Publishing  Subsystem  is  designed  to  create  and  maintain 
complex  flight  information  publications  (FLIPs)  used  by  military  pilots 
all  over  the  world.  The  major  functional  areas  are:  log-on/log-off, 
publication  identification  and  creation,  display  manipulation,  update 
pages,  file  management,  publication  reports  and  statistics,  repagination 
and  output  to  EBR,  and  publication  proofing.  Figure  2-7  depicts  the 
overall  functionality  of  the  Publishing  Subsystem. 

The  Aeronautical  Information  Department  (AD)  of  DMAAC  publishes 
flight  and  air  facilities  information.  These  publications  are  used 
by  DoD  agencies,  U.S.  Commands,  military  services,  and  other  author¬ 
ized  users  for  flight  operations  and  logistical  planning.  These  pub¬ 
lications  result  in  about  140  issues  and  1.5  million  lines  of  text 
per  year  with  a  50%  annual  character  change  rate.  The  data  base 
structure  of  the  Publishing  Subsystem  is  designed  to  accomodate  that 
data  necessary  for  the  production  of  the  publications  as  well  as  the 
ready  access  and  maintenance  of  the  data. 

The  Publishing  Subsystem  provides  a  well  human  engineered,  cost- 
effective,  high-quality  replacement  of  the  manual  document-to-tub 
f ile-to-varitype-to-tub  f ile-to-camera  system  it  replaces.  The 
subsystem  avoids  extensive  training,  excessive  errors,  operator  frus¬ 
tration,  and  production  delays.  Continuity  of  update  sessions  is 
insured.  The  subsystem  is  a  flexible  and  responsive  tool  that  is 
highly  automatic.  Additional  requirements  are  h i gh-quality  control 
through  system  proofing  aids  and  reports,  the  ability  to  distinguish 
symbology  in  update  mode,  comprehensive  error  diagnostics,  flexible 
error  correction  procedures,  and  dependable  automated  assistance. 


2.3. 1.1  Capabilities 

The  Publishing  system  as  developed  possess  many  unique  advantages 
over  existing  systems,  be  they  of  word  processing  or  typesetting  origin. 

a.  Utilization  of  a  CRT  which  displays  3960  characters 
of  text  at  once  (132  X  30). 


b.  On-line  hyphenation  and  justification  of  typesetting 
quality . 


Figure  2-7.  Publishing  Subsystem  Functional  Design 


c.  Multi-font  and  font  size  capability  including: 

1.  Individual  character  width  definition; 

2.  Automatic  leading  control,  permitting  any 
font/size  combinations; 

3.  Rapid  identification  of  font/size  on  the 
CRT ;  and 

4.  Accommodation  of  special  symbols  and  foreign 
languages . 

d.  Complete  automatic  repagination  capability  including 
page  breaking  controls,  column  balancing,  header 
generation  by  specification  and  from  context,  page 
numbering  format  control  (e.g.,  4-21  where  chapter 
number  prefaces  page  number) . 

e.  Comprehensive,  simple,  edit  capabilities  which  are 
easier  to  use  than  typical  word  processing  systems 
(because  they  combine  line  context  edit  capabilities 
with  cursor  positioning  capabilities)  yet  as  powerful 
as  typesetting  systems  because  automatic  on-line 
justification  occurs  simultaneously  with  update.  These 
include : 

1.  Insert; 

2.  Delete; 

3.  Change  (with  repeat  if  desired); 

4.  Search  (with  repeat  if  desired) ; 

5.  Position  cursor  (forward,  backward, 
up,  down,  by  line  number,  etc.); 

6.  Scrolling;  and 

7.  Hyphenation  defeat  or  override. 

f.  Multiple  column  definition 

g.  Nesting  of  columnation  (columns  with  columns) . 

h .  Left,  right  and  center  justification,  applying  to 
the  page  width,  column  width,  or  between  any  two 
specified  tab  positions  (e.g.,  center  justify 
between  positions  (1/2  pica)  10-50) . 
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i.  Diagram  insertion  and  maintenance  capability  eliminates 
manual  paste  up. 

j.  Tabulation  and  automatic  indent  controls. 

k.  Directory  access  to  multiple  versions  of  books 
and  chapters. 

l.  Flexible  book  and  chapter  format  definition,  or  on-line 
redefinition. 

m.  Complete  global  edit  capability  permitting  string 
substitution  or  deletion  and  simultaneous  re justification 
at  high  speed  throughout  the  document 

n.  Password  protection  by  function. 

o.  Maintenance  of  a  line  index  within  a  page  enabling 
direct  access  to  any  part  of  the  page  either  by 
cursor  positioning,  scrolling,  or  instantly,  by 
specifying  a  line  number. 

p.  Maintenance  of  update  bars  for  technical  publications. 

q.  Maintenance  of  CRT  and  proof  list  proofing  flags 
indicating  where  changes  have  occurred. 

r.  Complete  logging  of  all  commands  and  production  of 
a  management  information  report  based  upon  the  log. 

s.  Auxiliary  monitor  which  displays  typesetting  infor¬ 
mation  allowing  manual  override  of  automatic  decisions. 

t.  Proofing  mode  which  logs  approval  or  review  status 
enabling  document  control. 

u.  Ability  to  handle  a  variety  of  special  symbols, 
graphics  or  logos. 

v.  User  definition  and  automatic  system  maintenance  of 
and  access  to  any  desired  index  to  the  entire  publi¬ 
cation  (e.g.,  access  by  paragraph  number,  embedded 
text,  titles,  headers,  footnotes,  etc.). 

w.  Maintenance  of  pages  as  distinct  entities  enabling 
document  update  and  instant  access  by  referring  to 
the  original  page  number;  regardless  of  additions, 
changes,  reformatting,  or  deletions  in  the  interim. 

Text  is  not  redistributed  among  pages  until  repagi¬ 
nation  is  specified.  After  repagination  the  original 
is  separately  maintained  and  available  as  a  "version." 
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Storage  capacity  is  available  to  store  from  50,000 
to  1,200,000  pages  of  information  depending  upon 
configuration  selected. 

y.  Programmed  in  a  high  level  language  (FORTRAN) , 
allowing  rapid  additional  programming  and  support 
to  meet  specific  user  requirements  now  and  in  the 
future.  System  improvements  will  be  available  to 
users  without  hardware  upgrade. 

z.  Human  engineered;  training  courses  available  to  permit 
comprehensive  operator  training. 

aa .  System  controls  and  complex  features  when  not  invoked 
remain  invisible  to  the  operator.  The  system  can 
perform  at  the  operator's  level;  in  less  than  one  hour 
a  typist  with  no  previous  exposure  to  the  system  can 
compose  typographic  quality  correspondence. 

bb.  Usable  in  a  multi-user  environment  on  a  suitable, 
general  purpose  (currently  operational  on  a  Data 
General  ECLIPSE  minicomputer)  computer,  allowing 
users  to  run  other  applications  of  their  choice 
simultaneously.  Furthermore,  both  the  terminals 
and  the  printer  are  usable  for  other  user  applications 
when  not  used  for  publishing  or  word  processing 
applications . 

cc.  Automatic  column  balancing  and  page  makeup. 

dd.  Vertical  tabulation. 

ee.  On-line  HELP  function  for  interactive  format  and 
repagination  specification  assistance. 

ff.  Columns,  page  width,  tabs,  indents,  font/size, 
update  bars,  and  hyphenation  controls  propagate 
throughout  the  entire  document  but  can  be  easily 
redefined  at  any  chosen  place  in  the  text;  providing 
complete  and  flexible  format  control  of  any  document 
regardless  of  size  or  makeup. 

gg.  User  definable  function  keys  and  mnemonics  permitting 
the  automatic  entry  of  any  combination  or  commands  and 
textual  data  of  any  length. 
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The  data  base  structure  of  the  Publishing  Subsystem  is  designed 
to  accommodate  that  data  necessary  for  the  production  of  the  flight 
information  publications  prepared  by  the  Defense  Mapping  Agency  Aero¬ 
space  Center  and  to  provide  for  the  ready  access  and  maintenance  of 
this  data.  Care  has  been  exercised  to  avoid  restrictions  which  would 
likely  cause  substantial  redesign  and  conversion  when  enhancements  to 
the  subsystem  result  in  additional  maintenance  functions  and  access 
requirements . 

Where  repeated  occurrence  of  a  data  item  would  be  a  particular 
burden  on  storage,  maintenance,  or  manual  editing,  data  items  have 
been  incorporated  to  allow  relief  (as  in  the  case  of  alternate  font 
and  tabulation  specifier::). 

The  data  base  is  intended  to  be  supported  by  a  Data  General  Real 
Time  Disk  Operating  System,  although  there  are  no  inherent  aspects 
which  would  encumber  its  support  on  any  system  which  supports  a  mass 
storage  device  with  equivalent  characteristics  to  that  of  a  moving 
head  disk. 

Four  types  of  files  are  used  to  maintain  the  publications.  They 
are  linked  together  as  shown  in  Figure  2-8.  The  book  file  is  a  contiguous 
file  of  maximum  length  of  16,384  bytes.  There  is  one  book  file  for  each 
publication.  It  serves  as  an  index  to  each  of  the  chapter  versions  (CV's) 
comprising  the  publication.  The  chapter  file  contains  the  contextual 
and  formatting  data  for  the  publication.  The  font  files  contain  that 
data  needed  to  convert  the  chapter  file  font  designations  into  EBR 
designations.  The  page  index  file  is  generated  at  publication  time 
durinq  repagination  if  the  chapter  descriptor  contains  the  appropriate 
indicator.  It  is  used  to  address  pages  of  a  supplement  chapter  by 
facility  name.  Additionally,  there  are  system  utility  files  and  transient 
files  including  RDOS  command  file  (CoM-CM) ;  Publishing  Subsystem  Command 
File;  and  System  Log. 

a.  Book  File.  The  book  file  is  a  contiguous  file  of 

16,384  bytes  consisting  of  one  64  byte  header  followed 
by  as  many  as  255  64-byte  CV  discriptors  in  a  con¬ 
tiguously  organized  file. 


FILE  HEADER 


Description 

Bytes 

Contents 

1. 

File  type  identifier 

2 

"BK" 

2. 

File  type  version 

2 

0 

3. 

Number  of  bytes  in  header 

2 

64 

4. 

Number  of  bytes  per  entry 

2 

64 

5. 

Title  of  book 

^6 

ASCII 

6. 

Number  of  entries;  chapter 

1 

0  to  255 

versions  (CV's)  Filler 

39 

Nulls 

64 
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Structure 


CV  DESCRIPTOR  FORMAT 


Field  No. 

Field  Description 

Bytes 

Format 

Contents 

1 

Chapter  (CV)  Title 

16 

RADIX  40 

1-256 

2 

Chapter  Number 

1 

Binary 

1-256 

3 

Filler 

1 

Byte 

Null 

4 

Version  Number 

2 

Binary 

1-6561 

5 

Vertical  Page  Size 

2 

Binary 

Pica 

6 

Horizontal  Page  Size 

2 

Binary 

Pica 

7 

Chapter  File  Record  Size 

2 

Binary 

Bytes 

8 

Chapter  File  Size 

2 

Binary 

Records 

9 

Date  of  Last  Update 

2 

Binary 

Date 

10 

Date  of  Last  Publication 

2 

Binary 

0  or  Date 

11 

Size  of  Font  No.  1 

1 

Binary 

Points 

12 

File  Name  of  Font  No.  1  Data 

3 

ASCII 

FONTaaa . F 

13 

Size  of  Font  No.  2 

1 

Binary 

Points 

14 

File  Name  of  Font  No.  2  Data 

3 

ASCII 

FONTaaa. F 

15 

Size  of  Font  No.  3 

1 

Binary 

Points 

16 

File  Name  of  Font  No.  3  Data 

3 

ASCII 

FONTaaa .F 

17 

Size  of  Font  No.  4 

1 

Binary 

Points 

18 

File  Name  of  Font  No.  4  Data 

3 

ASCII 

FONTaaa . F 

19 

20 

Size  of  Page  Number  Font 

File  Name  of  Page  Number  Font 

1 

Binary 

Points 

Data 

3 

ASCII 

FONTaaa. F 

21 

Page  Number  of  First  Page 

2 

Binary 

1-32767 

22 

23 

Number  of  Pages 

Vert.  Page  Number  Position 

2 

Binary 

2-1024 

24 

(Top,  Bottom) 

Horiz.  Page  Number  Position 

1 

ASCII 

T,  B 

25 

(Inside,  Center,  Outside) 
Accompanying  Page  Number 

Data  (Title,  Nothing, 

1 

ASCII 

I ,  C ,  0 

26 

CV  Title,  CV#) 

Page  Index  File  Code 
(None,  Will  Generate, 

1 

ASCII 

T, Blank, C 

Yes,  Will  Stop) 

1 

ASCII 

Blank, G,Y 

Filler 

4 

64 

Bytes 

Nulls 

b.  Chapter  File  Design.  Each  chapter  file  is  a  contiguous 

MRDOS  file  containing  records  of  16,384  bytes  (32  sectors) 
each.  The  file  name  for  this  file  is  a  function  of  the 
book  title  and  the  chapter  and  version  number  as  speci¬ 
fied  in  the  CV  descriptor.  Each  of  these  records  repre¬ 
sents  one  page  of  data  as  it  would  appear  in  the  publication 
or  as  subsequently  updated.  Repagination  occurs  only  during 
EBR  output  tape  generation  at  publication  time.  Each  record 
contains  a  32-byte  header  containing  status  information 
carried  over  from  the  previous  page  followed  by  16,352  bytes 
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of  contextual  and  formatting  data  (see  Figure  2-9) . 
Although  16,352  bytes  is  triple  the  amount  of  room 
required  by  a  typical  page,  this  much  room  lias  been 
allocated  to  accommodate  extensive  modifications 
during  the  update  process.  Although  this  contiguous 
structure  will  result  in  disk  allocations  of  6.5 
million  bytes  for  some  publications  (versus  2 
million  for  a  more  compact  format) ,  the  fourfold 
(or  more)  decrease  in  record  access  time  makes  it 
well  worth  this  consumption  of  a  rather  minor  portion 
of  the  192  million  bytes  of  disk  storage. 

c.  Page  Record.  The  body  of  each  record  contains  16,352 
bytes.  Each  of  these  bytes  contains  an  ASCII  character 
in  the  low  order  seven  bits  and  an  update  flag  in  the 
high  order  bit.  At  publication  time  the  update  flags 
are  cleared.  As  data  is  subsequently  added,  it  is 
added  with  its  update  flag  set.  When  data  are  deleted, 
they  are  replaced  wi*Ci  a  byte  containing  a  null  with 
its  update  flag  set  (un Less  the  data  deleted  had  all 
update  flags  set),  one  such  null  for  each  string 
deleted. 

The  update  flags  are  used  to  indicate  what  data  lias 
been  modified  since  the  last  publication.  With  this 
the  solid  vertical  bars  can  be  automatically  placed 
to  the  left  of  the  column  or  page  indicating  that  a 
change  has  taken  place.  Whenever  a  publication  is 
generated  all  of  these  flags  can  bo  cleared.  Then 
as  data  is  added,  it  is  added  with  the  flag  set  and 
as  data  is  deleted  it  is  replaced  with  a  null  with  a 
set  flag  when  any  of  the  deleted  data  lias  a  cleared 
flag . 

The  following  table  contains  a  description  of  all 
data  items  which  can  be  included  in  the  ASCII  text 
data  string  within  a  chapter.  There  are,  however, 
two  major  divisions: 

1.  Operations- including  Opcodes,  specifiers, 
and  delimiters;  and 

2.  Nonoperations-including  null,  control  codes, 

ASCII  data,  and  indicators. 
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Figure  2-9.  Chapter  File  Format 


Octal  Code(s)  of 

First  Character  Data  Item  Type 
000  Null  or  Filler 


Oil  to  015  and  Control  Code 
021  to  024 


074  and  076  Operation 


040  to  177  ASCII  Data 

except  (074, 

076,  133,  135, 
and  137) 

133  and  135  Indicator 


137 


Indicator 


Functions 

To  take  up  space  or  (when 
the  update  flag  is  on)  to 
indicate  that  items  formerly 
in  this  position  have  been 
deleted  since  the  last 
publication. 

To  control  horizontal  (011) 
or  vertical  (013)  tabulation, 
paqe/column  control  (012  and 
015)  or  termination  (014)  , 
or  font/size  selection  (021 
to  024)  . 

To  specify  column  parameters, 
horizontal  or  vertical  tab 
positions,  font/size  selec¬ 
tions,  diaqram  placement, 
horizontal  iustif ication , 
hyphenation  or  columnation 
restriction,  titles,  or 
horizontal  column  spanning 
lines. 

To  specify  contextual 
publication  data. 


To  specify  enclosed  text  is 
to  be  underlined. 

To  specify  next  byte  contains 
a  special  or  circled  character. 


(a)  Operations  are  delimited  by  an  initial 

<  (Octal  074)  and  a  terminal>  (Octal  076) 
Between  the  delimiting  character  is  the 
one  or  two  character  opcode  followed  in 
some  cases  by  additional  specifiers. 

The  opcodes  are: 


Opcode 

Specif iers 

Function 

Level 

H 

No 

Horizontal  line  spanning  page  or 
column  (also  terminates  line) 

4 

CL 

Yes 

Specifies  column  parameters  for 
data  which  follows  (also  terminates 
line) 

3 

TC 

No 

Terminate  columnation 

3 
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Opcode 

Specifiers 

Function 

Level 

MS 

No 

Allow  midstream  column/page  breaks 

4 

TM 

No 

Don't  allow  midstream  columri/page 
breaks 

4 

TB 

Yes 

Set  horizontal  tab  stops 

4 

V 

Yes 

Set  vertical  tab  stops 

2 

LJ 

No 

Select  left  -justification  (normal) 

5 

CJ 

No 

Select  center  justification 
(between  tab  stops) 

5 

RJ 

No 

Select  right  justification  (to 
next  tab  stops 

5 

LD 

No 

Left  justify  in  a  field  of  dots 

5 

D 

Yes 

Specify  position  and  identification 
of  a  diagram 

5 

TL 

Yes 

Specify  a  column  title  (implicit 
column  break) 

4 

HY 

No 

Allow  hyphenation  (except  across 
pages) 

4 

TH 

No 

Terminate  hyphenation  allowance 

4 

The  level  numbers  indicate  under  what  circumstances 
the  operation  can  be  used.  Some  of  the  operations 
(CL,  TB,  V,  D  and  TL)  can  include  one  or  more  spec¬ 
ifiers  that  have  the  following  structure:  a  con¬ 
catenation  of  data  items  delimited  with  a  leading 
"<"  and  terminating  within  such  a  structure 

not  all  data  items  can  be  used.  Specifically,  only 
those  data  items  with  a  level,  number  greater  than  the 
level  number  of  the  item  containing  the  specifier 
can  be  used.  For  example,  suppose  a  diagram  is  to  be 
specified.  Once  of  the  specifiers  that  can  be  in¬ 
cluded  in  the  data  item  for  diagram  specification 
designates  the  identification  or  label  of  the  diagram. 
This  specifier  can  only  include  data  items  of  levels 
greater  than  5.  (5  is  the  level  of  diagram  specification 

item).  Therefore,  operation  type  data  items  cannot 
be  used  in  the  diagram  specification. 
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(b)  Non-operations  are  other  data  items  which  have 
the  following  levels: 

Data  Item  Level 

Null  or  filler  1 

Control  codes  5 

Operations  2-5  as  described  above 

ASCII  data  6 

During  data  entry  at  an  edit  session  the  level 
of  entry  starts  out  at  one;  therefore,  nulls 
cannot  be  entered  directly. 

There  are  nine  control  codes: 

Control  Code  Octal  Function  Level 

TAB  (fl)  Oil  Horizontal  tabulation  (like  5 

CR  if  no  tabs) 

LF  (tj)  012  Start  on  next  line  (next 

column  if  need  be)  5 

VT  (+K)  013  Vertical  tabulation  (like 

FF  is  no  vertical  tabs)  5 

FF  (dL)  014  Start  on  next  page/column  5 

CR  (tM)  015  Start  on  next  line  (same  5 

column  unless  opcode  MS) 

DC1  (tQ)  021  Select  font/size  1  5 

DC2  (+R)  022  Select  font/size  2  5 

DC3  (ts)  023  Select  font/size  3  5 

DC4  (tT)  024  Select  font/size  4  5 

When  font/size  3  or  font/size  4  is  selected, 
text  in  this  font  appearing  on  the  Datagraphix 
terminal  will  be  briaht.  At  pagination  time 
letters  in  font/size  4  will  be  used  to  build 
the  page  index  file  (if  generation  of  this 
file  is  indicated)  and  text  in  this  font  will 
be  displayed  just  prior  to  edit  time  as  pages 
are  turned  in  search  of  the  correct  page. 

Font  File  Design.  The  font  file  is  a  fixed  length 
contiguous  MRDOS  file  384  bytes  in  length.  The  name 
of  the  file  is  "FONT***.F"  where  "***"  is  any  alpha¬ 
numeric  characters.  The  file  is  made  up  of  96  four 
byte  entries  each  representing  one  of  the  96  ASCII 
characters  from  Octal  40  to  Octal  177.  Each  entry 


has  the  following  format  ("*"  represents  the  ASCII 
character  that  the  entry  data  describes) : 

Field  No  Field  Description  Bytes 

1  EBR  output  value  for  1 

2  Horizontal  increment  (in  points)  for  1 

a  9  point  "*" 

3  EBR  output  value  for  a  circle,  dot  or  1 

triangle  "*" 

4  Horizontal  increment  (in  points)  for  a  1 

9  point  circle,  dot,  or  trianqle  "*"  _____ 

TOTAL  4 


This  file  is  used  at  edit,  pagination,  and  EBR  output  time. 

e.  Page-index  file  design.  Generation  of  the  page-index 
file  occurs  at  repagination  and  EBR  output  generation 
time  in  response  to  an  indicator  in  the  CV  descriptor 
of  the  book  file.  The  page-index  file  is  a  sequential 
file  of  four  byte  ASCII  entries,  one  such  entry  for  each 
page  in  the  CV  file  to  which  the  index  supports.  The 
file  name  of  the  page-index  file  is  identical  to  the  file 
name  of  the  corresponding  CV  file  except  for  the  extension 
which  is  ".CV"  for  the  CV  file  and  ".PI"  for  the  paqe-index 
file. 

Each  four  byte  ASCII  entry  is  developed  from  the  first 
occurence  of  a  string  of  characters  in  font/size  4  in 
the  page  of  the  chapter  corresponding  to  that  entry. 

This  file  is  then  used  at  page  select  time  (durinq  an 
EDIT  session)  to  generate  a  page  number  from  a  facility 
or  paragraph  name. 

f.  The  Log  File.  The  log  is  a  sequential  file  of  strictly 
ASCII  data.  Each  entry  contains  the  following  data: 


#  Char 

Example 

Year 

2 

77 

Month 

3 

JUN 

Day 

2 

30 

Space 

1 

Hour 

2 

IB 

Colon 

] 
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#  Char 


Example 


Minute  2 

Space  1 

Command  2 

Space  1 

Other  Data  Such  as 
the  Book  Title 

Carriage  Return  1 

Sometimes  followed 
by  Other  Lines 
Which  Begin  with  a 
Space  and  End  with 
Carriage  Returns 


16 


DC 


The  Other  Lines  May  Include  Error  Messages: 


Space  1 

Error  Code  3 

Space  1 

Error  Message 
Possibly  Containing 
Parametric  Data 
Detailing  the  Error 
Condition 

Carriage  return  1 


100 


For  the  background  the  name  of  this  file  is 
$PUBBLOG.TB.  For  the  foreground,  $PUBFLOG . TB . 
These  files  are  maintained  in  chronologically 
ascending  order. 


Command  file  COM. CM,  The  action  taken  by  the 
Command  Line  Interpreter  (CLI)  upon  reading  a 
command  line  is  sufficiently  flexible  so  that 
users  can,  if  they  wish,  design  programs  to 
perform  system  command  functions. 


When  either  the  background  or  foreground  CLI 
reads  a  command  line  and  does  not  recognize  the 
first  file  name,  the  CLI  always  builds  a  com¬ 
mand  file  (preceding  the  loading  of  the  save 
file  of  that  name) .  The  command  file  reflects 
an  edited  version  of  the  command  line.  The  name 
of  the  command  file  is  COM. CM  if  it  is  built  by 


the  background  CLI .  The  foreground  CLI  builds 
a  command  file  identical  in  structure  to  COM. CM, 
but  the  foreground  command  file  is  named  FCOM.CM. 


h.  Command  File  5PUBBC0M.TB.  The  command  file  generated 
by  CLI  (COM. CM)  is  parsed  before  being  processed  by 
PUB.  This  parsed  data  is  approximately  the  same  ASCII 
data  as  was  entered  except  that  the  "PUB,"  and  the 
command  code  have  been  removed  and  the  file  is  termi¬ 
nated  by  two  consecutive  carriage  returns.  The  file 
is  sequential  and  is  named  $PUB.COM.TB  or  $PUBFCOM.TB 
for  background  or  foreground  respectively. 

2. 3. 1.3  Software  Functions 


The  software  components  of  the  Publishing  Subsystem  are  depicted 
in  Figure  2-10.  The  major  functional  areas  are  as  follows. 

a.  Log-on/log-off 

b.  Publication  identification  and  creation 

c.  Display  manipulation 

d.  Update  pages 

e.  File  management 

f.  Publication  reports  and  statistics 

g.  Repagination  and  output  to  EBR 

h.  Publication  proofing 

1.  Log-on/Log  off.  This  process  permits  access 
to  the  system  only  after  the  entering  of  a 
password.  A  hierarchy  of  password  validity 
insures  that  only  authorized  personnel  can 
utilize  specific  system  functionality.  For 
example,  the  password  QRSTWVW  may  grant 
access  to  publications  for  revision  and  up¬ 
date  but  not  for  repagination,  delete  book, 
etc . 

2 .  Publishing  Identification  and  Creation.  The 
functions  to  be  performed  under  this  category 
are : 

(a)  Print  book  or  chapter;  • 

(b)  Identify  or  select  book  or  chapter;  and 
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gure  2-10.  Publishing  Subsystem  Software  Components 


(c)  Update  book  or  chapter. 

A  book  file  serves  as  an  index  to  a] 1  chapters 
and  chapter-versions  (current  and  past  publica¬ 
tions  having  the  same  title  and  format) .  A  chap 
ter  file  contains  format  definition  and  heading 
information  as  well  as  the  text  and  operation 
codes  that  form  the  substance  of  the  publication 
Chapters  are  divided  into  page  divisions  until 
the  cut-off  point  in  a  publication  cycle  results 
in  repagination  and  output.  This  is  because  the 
best  reference  an  analyst  has  to  a  change  is  the 
page  on  which  it  appeared  in  the  last  published 
version.  If  page  divisions  were  not  maintained 
during  the  update  cycle  it  would  be  difficult 
to  reach  desired  places  within  the  publication 
as  text  migrated  from  page  to  page  reflecting 
update  activity. 

The  publishing  subsystem  maintains  indices  to 
pages  within  chapters.  This  practice  permits 
the  system  to  automatically  generate  chapter 
page  headers,  ensure  chapter  integrity  during 
repagination,  and  provide  faster  response  times 
than  associated  with  a  simple  book/page  index. 

Display  Manipulation.  At  the  core  of  the  Pub¬ 
lishing  Subsystem  is  the  ability  to  revise  the 
contents  of  an  existing  chapter.  To  actually 
perform  this  function,  however,  an  interface  to 
the  system  must  exist  which  permits  the  rapid 
display  of  that  body  of  text  which  must  be  up¬ 
dated.  It  is  this  vital  function  of  getting 
to  a  page,  moving  the  display  cursor  within 
the  page,  and  scrolling  the  display  which  is 
functionally  incorporated  into  'Display  Manip¬ 
ulation  '  . 

There  are  two  methods  of  reaching  a  page  be¬ 
fore  updating  a  chapter.  If  a  page  number  is 
specified,  the  system  will  retrieve  the  cor¬ 
responding  page  of  data  and  display  the  first 
12  lines  of  the  page.  One  may  scroll  forward 
to  view  the  remainder  of  the  page. 

Indexed  documents  permit  use  of  the  "+"  and 
keys  to  go  from  page  to  page  displaying 
facility  names  as  a  guide  to  page  content. 

The  "+"  pages  forward  and  pages  backward. 


Cursor-control  positions  the  cursor  for  add  and 
delete  functions,  as  well  as  causing  the  screen 
to  scroll  when  the  cursor  is  ordered  off  the 
screen. 

The  display  commands  offer  a  more  rapid  means  of 
controlling  which  part  of  the  page  is  to  be  shown 
on  the  screen.  Using  the  display  function  also 
provides  the  advantage  of  maintaining  the  cursor 
in  the  same  position  on  the  screen. 

4.  Update  Page.  The  Update  page  function  provides 
absolute  control  of  the  content  and  format  of 
the  document.  This  function  is  composed  of  the 
following  subsections: 

(a)  Manipulate  format; 

(b)  Search  for  string;  and 

(c)  Change/insert/delete  string. 

The  subsystem  has  the  ability  to  store  and 
manipulate  format  operands  such  as  tabulation, 
columnation,  justification,  hyphenation  control, 
font/size  selection,  and  diagram  insertion. 
Essentially,  the  operand  supplied  by  the  oper¬ 
ator  causes  a  command  to  be  stored  in  the  body  of 
the  text  which  results  in  correct  formatting  both 
on  the  screen  and  during  pagination. 

The  Update  function  permits  the  search  for  a 
given  string  or  combination  of  characters. 

It  is  used  both  as  a  cursor  positioning  func¬ 
tion  and  as  a  vital  subfunction  in  the  changing 
of  character  groups. 

Update  performs  the  function  of  actually  inserting 
characters  and  operands  into  the  page  of  text. 
Positioning  the  cursor  to  a  character  and  invoking 
the  delete  function  causes  the  character  to  be 
removed  from  the  page  of  text.  The  change  command 
is  used  to  replace  a  given  character  group  or 
string  with  another  of  the  same  or  different  size. 
Automatic  justification  will  expand  or  contract 
the  line  accordingly  after  this  command  is  invoked. 

Additionally  this  command  can  be  invoked  to  change 
any  number  of  consecutive  occurrences  of  a  string 
on  a  page  to  another  string  of  the  same  or  different 
size . 
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5.  File  Management.  Utilities  having  to  do  with  file 
management  include: 


(a) 

Update 

log  file; 

(b) 

Update 

font  file; 

(c) 

Store  package  files;  and 

(d) 

Create 

book  or  chapter. 

A  log  of  all  system  functions  is  kept  including; 

(a)  Function  performed; 

(b)  Time  of  day  performed; 

(c)  Date;  and 

(d)  Password  identification. 

From  this  log  management  statistics  may  be 
generated.  Additionally  a  proof  management 
report  reflecting  the  status  of  a  publication 
through  proofing  is  available  to  insure  adequate 
proof  management. 

The  font  file  forms  the  link  between  the  represen¬ 
tation  of  characters  within  the  publishing  subsystem 
and  their  depiction  upon  the  EBR  output  device. 
Essentially,  the  contents  of  this  file  are  the 
codes  by  which  the  EBR  will  recognize  the  character 
to  be  produced  on  the  film  prior  to  blow-up  to 
left  size. 

6.  Publication  Statistics.  Publication  statistics 
are  collected  and  may  be  displayed. 

Since  all  changed  characters  are  flaqged  it  is 
possible  to  derive  a  number  representing  the 
number  of  characters  entered  to.  the  publication 
(though  not  the  number  deleted) .  Net  change  can 
be  calculated  by  comparinq  the  character  counts 
for  successive  publications.  These  statistics  are 
normally  retrieved  and  printed  for  management 
use. 

7.  Repaginate  and  output  process.  The  repaginate 
and  output  process  is  the  most  complex  function 
of  the  Publishing  Subsystem.  All  the  embedded 
operands  controlling  format  are  translated  into 
a  completed  product.  The  constituents  of  the 
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repaginate  function  are: 

(a)  Identify  the  publication; 

(b)  Perform  global  edits; 

(c)  Paginate  the  publication; 

(d)  Create  new  indices;  and 

(e)  Output  the  EBR  tape. 

The  function  requires  bringing  in  all  relevant 
book  and  chapter  descriptors  and  parameters 
that  define  page  headings,  leading  requirements, 
etc.  In  addition  this  function  brings  in  a 
global  edit  file  which  permits  the  changing  of 
one  character  string  for  another  throughout  the 
entire  chapter.  This  capability  would  facilitate 
the  incorporation  of  new  abbreviations  on  the 
chanqing  of  symbology  automatically. 

Durinq  global  revision  pages  are  brought  in 
and  merged  into  a  depaqinated  output  stream. 

This  stream  is  then  checked,  a  group  of  char¬ 
acters  at  a  time,  to  accomplish  the  substitution 
of  one  set  of  characters  for  another  that  consti¬ 
tute  the  global  revision  function. 

The  depaginated  globally  revised  stream  is  trans¬ 
formed  into  a  new  chapter  version  with  new  page 
numbers.  Other  subfunctions  include: 

(a)  Vertical  and  horizontal  leadiriq; 

(b)  Look  ahead  ability  to  space  >ut  a  page;  and 

(c)  Determination  of  best  fit. 

Many  of  the  functions  contained  here  are  used 
during  update  on  a  sinqle  page  at  a  time  to 
depict  the  page  in  as  close  a  manner  as  pos¬ 
sible  to  the  way  the  repaginate  function  will 
actually  treat  the  data. 

Page  indexinq  requires  the  building  of  a  page 
index  for  selected  publications  corresponding 
to  the  first  four  letters  of  a  facility  name. 

This  enables  rapid  entry  into  the  chapter  when 
the  page  number  is  not  shown.  Any  text  on  the 
page  may  be  used  as  an  index  to  the  chapter. 


The  final  stage  is  the  translation  process 
whereby  the  revised  and  paginated  chapter 
is  converted  to  a  format  usable  on  the  EBR 
output  device.  Once  the  translation  has 
occurred  the  formatted  publication  becomes 
available  to  the  Chartina  Subsystem  as  a 
magnetic  tape  for  merging  the  necessary 
graphics  with  the  formatted  pages  pro¬ 
duced  on  the  Publishing  Subsystem. 

Publication  Proofing.  The  Publishing 
Subsystem  is  designed  to  permit  a  high 
degree  of  versatility  while  satisfying 
the  other  design  objectives  of  cost- 
effectiveness,  speed,  high  quality  con¬ 
trol,  and  ease  of  use.  Versatility 
permits  AD  to  structure  their  data  flow 
and  related  personnel  procedures  in  a 
manner  which  AD  manaaement  feels  best  fits 
their  needs.  Synectics  has  not  presumed 
to  forecast  such  policy  decisions,  but 
has  provided  the  capability  to  operate 
the  update  and  proof  functions,  and  to 
maintain  an  on-line  status  log  for  each 
activity.  Such  a  capability  would  permit, 
for  example,  person  A  to  "edit"  changes 
from  a  given  batch  of  green  slips  while 
person  B  would  "proof"  the  changes  gen¬ 
erated  by  that  batch.  The  system  would 
maintain  a  management  log  of  what  work 
was  revised,  what  was  proofed,  and  what 
remains  to  be  proofed. 

An  important  facet  of  quality  control  is 
the  ability  to  maintain  accurate  compostion 
control  parameters  (e.q.,  font  and  type  size 
parameters).  Thus,  composition  control  para¬ 
meters  are  not  displayed  unless  requested  and 
are  not,  therefore,  normally  available  for 
revision.  Durinq  proofing  they  can  be  requested 
for  display  on  the  CRT  or  line  printer. 

Although  the  Publishing  Subsystem  is  an  inter¬ 
active  system  and  all  updatinq,  proofing,  and 
revision  functions  can  easily  be  performed 
through  the  system  terminal ,  provisions  have 
been  made  for  generating  hardcopy  listinqs, 
chapters  or  books  including  composition. 


During  proof  sessions  no  updates  or  revisions 
to  the  document  can  be  effected.  To  accomplish 
an  update  the  reviewer  must,  at  minimum,  exit 
proof  mode  and  log-on  in  update  mode.  The 
operation  sees  the  first  12  lines  of  text  on 
the  page  just  as  in  update  mode.  Format  is 
verified  on  the  terminal  moving  the  cursor  to 
the  next  change  in  composition  control  para¬ 
meters  and  observing  the  small  display  of  the 
font,  type  size,  and  lead  for  the  text  that 
follows.  Showing  the  proofer  exactly  what  font 
and  type  size  is  being  specified  rather  than 
trying  to  simulate  the  font  and  size  on  the  CRT 
should  help  maintain  a  higher  degree  of  quality 
control.  Exact  presentation  of  font  and  type 
size  parameters  does  not  leave  any  decision  to 
chance  interpretation  of  what  is  meant  to  be 
presented . 

The  design  of  the  proofing  function  placed 
considerable  emphasis  on  human  factors  and 
quality  control. 

(a)  All  currently  used  symbols  are 
available  through  the  terminal . 

(b)  Composition  control  parameters  are 
protected. 

(c)  "Update/Proof"  management  log 
protects  system  integrity. 

(d)  Items  are  retrieved  by  paqe  or 
name . 

(e)  Chapter  page  headers  are  generated 
automatically. 

(f)  Publication  parameters  and  user 
commands  are  segregated  from 
publication  text. 

(g)  The  last  command  is  displayed  in 
addition  to  current  or  next  command. 

2.3.2  Air  Facilities 


The  Air  Facilities  Subsystem  is  tasked  with  the  responsibility  of 
maintaining  the  AAFIF  data  base  and  supporting  on-line  queries,  selec¬ 
tive  data  base  retrieval,  AAFIF  special  report  generation,  scheduled 
tape  and  hardcopy  report  generation,  and  generation  of  formatted  tape 
files  for  the  Charting  output  device  to  record  film  positives  of  the 
ASSOTW  report.  (Reference  Figure  2-11.) 
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Figure  2-11.  Air  Facilities  Subsystem  Functions 


The  subsystem  is  required  to  receive  input  in  the  form  of  AAFIF 
update  request  forms,  special  air  information  requests,  interactive 
analyst's  queries  and  data  entry  through  local  and  remote  terminals, 
and  auxiliary  tape  input  for  AAFIF  conversion.  The  provision  of  data 
base  processing,  update  and  retrieval,  hardcopy  printout,  output  and 
ASSOTW  EBR  tape  processing,  security,  and  special  report  generation  are 
additional  requirements  of  the  subsystem.  Compliance  with  these  require¬ 
ments  results  in  the  following  outputs:  extracted  subsets  of  AAFIF 
data  base,  AAFIF  special  reports,  special  and  scheduled  tape  and  hard¬ 
copy  products  from  AAFIF  data  base,  and  ASSOTW  EBR  tapes  for  the  Charting 
Subsystem.  The  Air  Facilities  Subsystem  also  provides  the  means  for 
displaying  AAFIF  file  contents  for  analyst's  review  (local  and  remote). 

The  Air  Facilities  Subsystem  data  base  is  designed  to  assist  in 
the  maintenance  and  production  of  ASSOTWs,  SAIRs,  and  update  functions 
by  the  Defense  Mapping  Agency  Aerospace  Center.  The  effort's  main 
purpose  was  to  create  an  on-line  retrieval  and  update  system  that 
permitted  interactive  dialogues  between  users  and  the  computer.  This 
subsystem  contains  the  45,000  airfield  records  of  the  AAFIF  data  base 
and  completes  an  average  of  2,000  update  transactions  per  day.  The 
major  functional  areas  of  the  Air  Facilities  Subsystem  are:  data  base 
initialization,  data  base  update,  data  base  retrieval,  product  output. 
These  areas  allow  the  subsystem  to  fulfill  its  requirements  to  AAIPS 
as  well  as  utilizing  the  Automated  Air  Facilities  Information  File  (AAFIF) 


2. 3. 2,1  Capabilities 

The  following  capabilities  are  provided  by  the  Air  Facilities 
Subsystem: 

a.  On-Line  Capability.  This  provides  a  capability  to  per¬ 
form  AAFIF  data  base  maintenance  by  permitting  the  operator 
to  add,  change,  or  delete  individual  data  elements  or 
whole  records  with  ease  and  timeliness. 

1 .  Log-on/Log-off 

(a)  Include  an  access  authorization 
capability  through  a  combined 
password  processing  and  geo¬ 
graphic  identifier  validation 
scheme.  Correlate  password  and 
geographic  identifier  for  proper 
match. 

(b)  Ensure  that  the  operators  cannot 
access  the  command  language  of  the 
operating  system  (CLI)  or  the  facil¬ 
ities  of  the  AAFIF  system  programs. 


(c)  Provide  a  log-off  function  with 
reactivation  of  all  access  con¬ 
trols. 

2 .  Display  Processing 

(a)  Generate  display  files  or  menus  for 
on-line  communications  that  lead  the 
operator  as  well  as  the  on-line  soft¬ 
ware  to  proper  display,  decision,  and 
processing  sections. 

(b)  Make  the  display  processing  functions 
safe  (avoidance  of  system  crashes)  as 
well  as  clear  and  self-explanatory 
(teaching-machine  characteristics) . 

(c)  Create  display  files  and  display  file 
structures  with  application  area 
designations,  retrieval  indexes,  dis¬ 
play  text,  header,  and  communication 
(error)  messages  and  subroutine  call 
arguments. 

3.  Input  Processing 

(a)  Program  a  special  on-line  data  input  module 
with  automatic  cursor  positioning  and  'tick 
mark'  generation  to  indicate  (and  limit)  the 
input  field  on  the  screen. 

(b)  Include  simple-to-use  input  conversion 
capabilities  such  as  character  delete, 
line  delete,  input  escape,  and  possible 
exit  to  a  previous  program  level . 

4 .  Retrieval 

(a)  Establish  a  simple  record  identification 
procedure  with  retrieval  modes:  single 
element,  groups  of  elements,  page/contin¬ 
uation  page,  and  the  retrieval  of  multiple 
data  elements  (e.g.,  multiple  runways  per 
airfield) . 

5 .  Update 

(a)  Allow  for  a  single  element,  group  of 
elements,  page/continuation  page,  and 
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'multiple'  on-line  update  capability. 

Hold  all  updates  for  final  validation 
(logic  checks) . 

(b)  Perform  automatic  format  checks  for  each 
data  element  entered.  Give  immediate  in¬ 
put  error  indication  with  options  to  repeat 
or  skip  the  faulty  data  element  input. 

(c)  Create  a  temporary  file  containing  all  up¬ 
date  information.  Ensure  that  file  is 
saved  in  case  of  system  failures  (e.g., 
power  outages) ,  or  can  be  requested  to  be 
saved  (in  case  of  update-rejections  due  to 
logical  checks)  for  later  continuation  or 
update  correction. 

(d)  Perform  logical  checks  that  correlate 
selected  data  base  elements  to  make  sure 
that  entries  fall  within  reasonable  ranges 
and  that  correct  information  categories 
have  been  chosen  (i.e.,  make  sense).  Pre¬ 
vent  updates  that  do  not  pass  logical  checks 
from  being  entered  into  the  data  base. 

(e)  Provide  for  an  automatic  update  function 
(computed  input)  that  is  triggered  by  the 
update  of  other  data  base  elements,  cor¬ 
related  by  logical  tables  (usually  for  a 
changed  data  category  that  represents  a 
group  of  related  elements) . 

(f)  Implement  on-line  text  edit  and  update 
capabilities  with  string  search,  string 
replacement,  and  update  verification 
schemes . 

Add 

(a)  Program  a  capability  for  the  on-line 
addition  of  an  entire  airfield  to  the 
data  base.  Assure  a  guided,  page-wise, 
and  item-by-item  information  entry  that 
avoids  skipped  data  fields  and  human 
oversights . 

(b)  Make  the  elaborate  UPDATE  functions 
available  to  the  ADD  process  by 
generally  treating  the  ADD  process — 
including  format  tests,  logical  checks, 
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and  computed  inputs -as  an  UPDATE  of 
a  (previously  'empty')  record. 

7.  Delete 

(a)  Provide  a  special  password/DELETE  function 
correlation  through  a  system  access  table 
in  order  to  ensure  that  the  somewhat  dan¬ 
gerous  deletion  of  an  entire  airfield  from 
the  data  base  can  be  accomplished  only  by 
specific,  designated  personnel. 

(b)  Generate  log  and  special  output  for 
deleted  airfields. 

8 .  Transaction  Log 

(a)  Maintain  a  periodic  access  file  containing 
terminal  and  airfield  information,  geo¬ 
graphic  identifier,  date,  and  time-of-day. 

(b)  Keep  log  of  all  transactions  (UPDATES,  ADDS, 
DELETIONS)  as  they  effectively  alter  the 
data  base  after  passing  format  and  logical 
checks . 


Save  and  Restart  Capability 


(a)  Provide  capability  for  using  the  temporary 
file  that  contains  all  update  information 
as  a  SAVE  file  to  continue  the  update  pro¬ 
cess  after  a  system  outage  or  operator 
interruption . 


(b)  Transfer  each  data  base  transaction  to 
disk  for  safer  storage  than  a  file  in 
main  memory. 


(c)  Implement  a  deliberate  save-file  capa¬ 
bility  to  be  used  by  the  operator  to 
preserve  an  incomplete  update  session 
(transfer  of  the  'temporary  file'  to 
another  that  will  be  kept  for  later 
recall). 
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10.  Data  Dictionary 


(a)  Provides  a  means  to  define  and  manage 

air  facility  information  by  identification 
of  AAFIF  elements  on  a  schema/subschema  level. 

(b)  Provide  for  evolving  AAFIF  data  content  by 
being  capable  of  displaying  and  editing  the 
schema/subschema  definitions. 

11 .  Boolean  Retrieval 

(a)  Provide  a  Bool«;an  search  capability  for 
retrieving  specific  airfield  records  from 
AAFIF  based  on  prescribed  information  con¬ 
tents  by  determining  the  selection  criteria 
interactively. 

(b)  Provide  capability  to  limit  the  area  of 
search  by  specifying  geographic  boun¬ 
daries  and/or  WAC  cell  ranges. 

12.  Applications  Programs 

The  applications  programs  deal  with  a  larger 
section  of  the  data  base  and  are  intended  to 
produce  reports  and  magnetic  tape  outputs  to 
be  used  by  other  departments  of  DMAAC  and  other 
agencies . 

(a)  Provide  sort  capabilities  that  allow 
complex  sort  key  specifications  and 
processing.  Implement  multi-pass 
sorting. 

(b)  Provide  a  report  generation  capability 
for  both  hardcopy  and  magnetic  tape 
output . 

(c)  Provide  an  interface  for  FORTRAN 
programs  to  support  blocked  data  base 
records  with  INFOS  structure  independence. 

(d)  Provide  a  COBOL  interface  to  allow 
applications  programs  to  access  the 
data  base  and  acquire  an  entire  sub¬ 
category  of  data  elements  at  one  time. 


(e)  Provide  a  capability  to  add  airfield 
records  entered  through  a  card  reader. 

(f)  Provide  an  ASSOTW  program  which  outputs 
an  EBR  tape  for  subsequent  film  positive 
recording. 

(g)  Provide  an  AFFINDEX  program  which  produces 
an  index  report. 

(h)  Provide  an  AFFUPDT  program  to  generate  the 
DIR  transaction  tape. 

(i)  Provide  a  HISTDUP  program  to  output  the 
AAFIF  history  file  on  tape. 

(j)  Provide  software  to  permit  loading  of  the 
U1108  AAFIF  file  from  tape. 

(k)  Provide  a  means  to  reconfigure  the  AAFIF 
data  base  when  it  becomes  necessary  to 
add,  change,  or  delete  element  schema/sub¬ 
schema. 

(l)  Provide  a  means  to  reconfigure  the  AAFIF 
data  base  when  new  countries  are  created 
or  when  analyst  assignments  change. 

13 .  AFFIF  System  Programs 

(a)  Design  System  Tables  for  display  control, 
data  base  element  identification,  and  edit 
table  selection. 

(b)  Provide  capability  for  establishing  pass¬ 
word  tables  and  their  easy  modification. 

(c)  Develop  edit  tables  for  format  tests,  logical 
correlations  of  data  base  elements,  computed 
(automatic)  inputs,  Boolean  retrievals,  pass¬ 
word,  and  Geo-Id  correlations. 

(d)  Provide  input  programs  with  table  headers 
and  automatic  tab  settings  for  the  on-line 
creation  of  system  and  edit  tables. 

(e)  Create  test  programs  for  the  on-line  testing 
and  changing  of  edit  tables. 
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(f)  Implement  a  display  session  file  with 
hardcopy  output  for  edit  table  documen¬ 
tation  . 

(g)  Provide  a  card  input  program  for  the 
'wholesale'  loading  of  generated  edit 
tables . 

(h)  Devise  programs  for  formal  table  checks, 
load  module  generation,  and  systems 
loading . 

2. 3. 2. 2  Design  Criteria 

a.  Air  Facilities  Subsystem  Design.  The  major  emphasis 
of  Phase  II  was  placed  on  providing  a  complete  sys¬ 
tem  hardware  configuration  to  support  remote  terminals 
for  multi-user  access  to  the  full  on-line  AAFIF  data 
base.  A  Data  General  M-600  computer  system  with 
sufficient  on-line  disk  capacity,  communications 
multiplexing  components,  and  a  sophisticated  real¬ 
time  multiprogramming  operating  system  was  acquired 
and  installed. 

The  Phase  II  Air  Facilities  Subsystem  hardware  con¬ 
figuration  deviated  only  slightly  from  the  original 
AAIPS  Design  Report.  The  design  called  for  fourteen 
remote  user  terminals  and  two  terminals  local  to  the 
processor.  Due  to  the  relocation  of  the  ADA  pro¬ 
grammers  and  operators  to  the  AAIPS  facility  in 
Building  3  it  was  agreed  that  there  would  be  ten 
(10)  remote  terminals  in  Building  4  to  support  the 
AIS  users  in  that  building.  Four  (4)  terminals  would 
be  placed  in  a  secured  vault  adjacent  to  the  AAIPS 
facility  for  use  by  the  AIS  users  in  Building  3.  The 
remote  terminals  in  Building  4  would  operate  at 
4800  bps  via  Government  supplied  encrypt/decrypt 
devices  which  would  interface  to  the  communications 
multiplexers  supplied  by  Synectics.  Synectics  also 
supplied  short  haul  modems  (line  drives)  which 
perform  digital/analog  conversion  of  line  signals 
and  interface  to  the  encrypt/decrypt  equipment. 


b.  AAFIF  Data  Base  Redesign.  A  data  base  structure 
redesign  to  permit  the  full  AAFIF  file  to  reside 
on-line  and  to  facilitate  rapid  retrieval  for  both 
interactive  and  applications  program  processing  was 
performed  during  Phase  II.  In  order  to  accommodate 
the  scheduled  tape  and  report  production  and  the 


nonscheduled  special  air  information  requests 
auxiliary  file  structures  were  developed. 

The  PILOT  INFOS  structure  was  designed  with  each  data  element 
having  its  own  multi-level  key.  This  was  very  flexible,  but  very 
costly  in  terms  of  INFOS  overhead. 

AAIPS-II  Considerations: 

a.  retrieval  time  (for  airfield); 

b.  efficient  utilization  of  disk  space; 

c.  simple  INFOS  structure; 

d.  ability  to  support  evolving  AAFIF  data  requirements; 

e.  programming  language  independence; 

f.  maximize  PILOT  software  legacy;  and 

g.  support  a  variety  of  access  types. 

The  following  were  the  PHASE-II  AAFIF  Data  Base  Design  goals: 

a.  minimize  the  INFOS  index  levels; 

b.  effective  utilization  of  index  space; 

c.  data  storage  efficiency; 

d.  retrieval  types; 

e.  blocking  factor  effects; 

f.  data  dictionary  "Concept"  AOS  application  interface; 

g.  effective  use  of  M-600; 

h.  hierarchically  organized  airfield  data;  and 

i.  multi-language  support. 

The  following  items  were  incorporated  in  the  PHASE-II  design 
to  overcome  limitations  of  PILOT  AAFIF  data  handling: 

a.  additional  WAC  coordinate  limit  calculations; 

b.  generation  of  UTM  coordinates; 
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c.  ability  to  change  airfield  elements  during  add  or  update; 

d.  deletion  and  entry  rejection  of  control  characters  in 
text  element  fields; 


e.  removal  of  printed  copy  option  from  CRT;  and 

f.  enhanced  logic  checking  capabilities  during  add  or 
update . 

2. 3. 2. 3  Subsystem  Data  Base 


The  AAFIF  data  base  contains  approximately  45,000  records  of 
air  facilities  information.  It  is  anticipated  that,  during  production, 
there  will  be  about  2,000  updates  per  day.  The  data  base  structure 
has  been  designed  to  accommodate  all  the  information  necessary  for 
their  update  and  maintenance. 


A  major  effort  of  the  project  was  the  reformatting  of  the  AAFIF, 
resulting  in  a  new  data  base  definition  (Label  Book) .  A  major  feature 
was  the  establishment  of  a  unique,  4-character,  retrieval  code  for 
each  data  element  of  an  airfield  record,  and  the  accompanying  descri- 
tive  element  name  (label) . 


The  retrieval  code  is  used  as  an  'address'  to  access  a  specific 
airfield  data  element.  However,  both  retrieval  codes  and  descriptive 
element  names  are  only  stored  once  in  the  system  to  eliminate  redundant 
information  from  storage.  As  a  consequence,  the  actual  data  base  con¬ 
tains  only  the  'essential'  information  for  the  specific  element  of  an 
airfield.  tor  the  ease  of  human  interpretation,  retrieval  codes; 
descriptive  labels;  and  the  actual  element  information  are  always 
combined  on  the  screen.  At  present  an  airfield  record  contains  over 
640  data  elements  organized  in  'pages'  that  correspond  to  87  sub¬ 
categories.  The  data  base  elements  can  contain  regular  alpha  or 
numeric  fields,  narrative  text,  or  multiple  entries  (e.g.,  to  accomodate 
the  information  for  several  runways  of  an  airfield) . 

The  element  retrieval  codes  and  descriptive  labels  are  stored  in 
special  tables  (Label  Tables) .  In  addition,  important  control  informa¬ 
tion  is  included  in  those  tables  for  program  selection;  display  control; 
edit;  multiple;  and  text  processing  instructions.  In  this  way  a  data- 
driven  capability  of  function  selection  has  been  achieved  that  allows 
specific  and  detailed  control  down  to  the  element  level  of  the  data 
base. 


For  the  Phase  II  system  both  tables  and  data  base  elements  have 
been  stored  on  disk  using  the  Data  General  INFOS  data  base  management 
package. 
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a.  AAFIF  INFOS  Structure.  Figures  2-12  and  2-13  present 
the  PHASE-II  AAFIF  INFOS  structure.  It  is  a  multi-level 
DBAM  file  with  3  levels  of  keys.  A  key  for  a  subcategory 
is  comprised  of: 

1.  LEVEL  0  —  SELECTOR  MODE; 

2.  LEVEL  1  —  WAC/INSTALLATION/COUNTRY-CODE/PROVINCE;  and 

3.  LEVEL  2  —  CATEGORY/SUBCATEGORY/OCCURRENCE. 

Using  this  key  structure,  an  entire  subcategory  can  be 
read  within  three  or  four  (3-4)  disk  accesses. 

b.  Variable  Blocked  Data  Base  Records.  The  approach  taken 
during  PHASE-II  was  to  combine  data  elements  into  sub¬ 
category  groups  and  to  handle  multiples  as  occurrences 
of  subcategory  groups.  Since  each  subcategory  is  a 
different  length,  variable  length  data  base  records 
are  supported.  Figure  2-14  shows  a  layout  of  this 
design. 

AAFIF  data  base  records  consist  of  2  parts:  A  Record  Map 
and  a  Data  Part-  The  Record  Map  contains  this  information 

1.  position  in  record  where  data  starts; 

2.  position  in  record  where  data  ends; 

3.  a  3-word  field  for  each  record  entry;  and 

4.  the  3-word  field  contains  the  status,  starting 

position,  and  length  of  each  data  element  in 
the  record. 

c.  AAFIF  Minifile.  The  AAFIF  minifile  consists  of  a 
subset  of  significant  air  facilities  elements  extracted 
from  each  AAFIF  airfield  record.  The  file  permits  rapid 
retrieval  for  use  by  SAIR/DAIR  processing. 

d.  AAFIF  Card  Image  File.  This  file  is  equivalent  in  format 
to  the  current  card  coded  U1108  AAFIF  file.  It  is  used 
to  facilitate  the  output  of  the  history  file  tapes. 


2. 3. 2 -4  Subsystem  Software 

The  software  organization  and  control  process  of  the  subsystem 
software  is  shown  in  Figure  2-15. 
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2. 3. 2. 4.1  Interactive  Processing.  The  on-line  Retrieval 
and  Update  capability  of  the  Air  Facilities  Subsystem  employs  several 
software  modules  and  series  of  tables  with  software  characteristics 
that  perform  complex  functions  in  a  very  straight-forward  and  simple 
to  use  manner.  The  implementation  of  important  software  functions  and 
their  associated  data  in  table  form  enables  the  user  to  maintain,  ex¬ 
pand,  and  (if  necessary)  restructure  the  system  through  data  entries. 

By  avoiding  software  changes  and  reprogramming  efforts  in  areas  most 
vital  to  the  user,  a  high  degree  of  vendor  independence  and  system 
flexibility  has  been  achieved.  This  adaptability  to  changed  situations 
will  make  the  system  more  responsive  to  the  changing  needs  of  DMAAC  and 
is  almost  certain  to  save  considerable  amounts  of  cost  and  time  in  the 
future. 


a.  Displays .  Two  basic  types  of  displays  are  used  to 
attain  smooth  interfaces  between  the  user  and  the 
computer : 

1.  menu-oriented  displays  that  permit  the  user 

to  select  from  a  variety  of  possible  options;  and 

2.  retrieval  displays  for  updating  data  elements 
of  any  record  in  the  system. 

The  menu-oriented  displays  provide  the  interfaces  for  the 
various  processing  functions  such  as  log-on,  password 
processing,  updates.  Boolean  searches,  and  so  on.  They 
allow  a  menu-oriented  dialog  that  guides  both  the  user 
and  system  to  any  one  of  the  required  display  data  input, 
processing,  and  error  checking  routines.  They  perform 
this  task  in  a  systematic  and  safe  manner  that  avoids 
operator  confusion  and  system  crashes. 

The  retrieval  displays  present  small  sections  of  the 
data  base  information  for  on-line  review  and  update 
procedures.  The  display  is  graphically  divided  into 
three  areas. 

1.  The  Display  Header  with  essential  record 
information  (WAC,  Inst.  No.,  Country  Code/ 

Province),  geographical  identifier,  date, 
and  time.  The  Display  Header  stays  the  same 
during  the  update  transactions  of  an  air  field 
(which  might  encompass  several  display  'pages’). 

2.  The  main  display  portion  depicting  a  section  or 
'page'  of  the  current  data  base  information  with 
identifying  labels,  and  a  data  entry  field  for 
new  inputs  or  updates. 
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3.  A  communications  area  for  the  display  of 
error  messages  and  the  input  of  program 
control  decisions.  Whenever  an  input 
error  is  encountered  while  updating  the  main 
section  (2) ,  this  communications  area  will  be 
displayed  with  appropriately  selected  error 
messages  and  response  options. 

b.  Tables.  Four  types  of  tables  are  involved  in  the 

processing  of  the  retrieval  displays. 

1.  Label  Tables,  containing  data  base  element 
identification  codes,  element  descriptions 
(labels) ,  display  processing  instructions, 
references  and  program  control  information 
for  required  format  and  logical  checks. 

2.  Format  Check  Tables,  that  specify  in  detail 
which  specific  input  data  or  type  of  input 
data,  is  acceptable  as  ‘new*  or  ’update’ 
information.  The  appropriate  format  check 
table  will  be  evaluated  immediately  after 
each  input  has  been  completed.  In  case 

of  a  format  failure,  the  cursor  will  jump 
into  the  communications  area  (3) ,  with 
appropriate  messages  and  response  options 
displayed  for  remedial  actions. 

3.  Logical  Check  Tables.  The  format-correct 
update  information  for  an  air  field  will  be 
held  in  a  temporary  SAVE  file  until  all  inputs 
for  that  air  field  have  been  completed.  They 
are  then  made  subject  to  logical  checks  that 
test  for  valid  interrelations  between  various 
data  base  elements. 

There  are  many  instances  where  a  format- 
correct  input  still  could  be  'false' — or 
make  no  sense — if  correlated  with  other 
information  for  that  air  field.  This 
correlation  is  performed  by  the  Logical 
Check  Tables.  Their  extensive  use  can 
make  the  system  quite  'intelligent'  by 
constantly  applying  supervisory  functions 
to  the  actions  of  a  less  knowledgeable  — 
or  less  alert  —  group  of  users.  In  cases 
where,  due  to  complexity,  certain  inputs 
should  be  made  by  the  computer  itself 
(rather  than  by  the  human  operator) ,  the 
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SET  command  of  the  Logical  Tables  implements 
these  inputs  correctly  and  automatically. 

4.  Communication  Tables  of  the  menu-oriented 
display  type.  In  case  of  an  input  error  or 
the  completion  of  a  page  update ,  the  appropriate 
communication  display  with  messages  and  response 
processing  options  will  be  presented  to  the  user 
for  a  decision  on  how  to  proceed. 

An  important  effort  of  the  project  was  the  reformatting  of  the 
AAFIF  into  an  acceptable  data  base  structure.  This  effort  resulted 
in  a  document  titled  "System  Design  Plan  and  Specification  for  AAIPS; 
Appendix  C,  AAFIF  Data  Base  Definition"  ('Label  Book').  Its  major 
feature  was  the  establishment  of  a  unique,  four-character ,  retrieval 
code  for  each  data  element  of  an  airfield  record,  and  the  accompanying 
descriptive  element  name  (label) . 

The  Label  Book  contains  the  identifying  labels  for  each  of  the 
over  600  data  elements  of  an  airfield  record.  The  subsequently 
generated  tables  contain  this  information  on  a  page-by-page  basis. 

Those  pages  are  stored  only  once  in  the  system  to  be  used  for  all 
records  (airfields) .  However,  a  page  will  always  be  displayed  on  the 
Datagraphix  terminal  along  with  the  corresponding  information  of  a 
particular  airfield  retrieved  from  the  data  base.  With  this  approach 
a  specific  label  table  has  to  be  brought  into  the  main  memory  for  every 
display  page  to  be  processed.  The  table  information  is  then  combined 
on  the  screen  with  pertinent  airfield  data  for  the  ease  of  human  review 
and  processing. 

Synectics'  table-driven  solution  to  the  editing  problem  does  not 
require  program  developments  or  program  alterations  to  accommodate 
changing  requirements.  It  permits  the  ready  system  loading,  testing,  and 
documentation  of  changed  or  new  edit  fables  in  an  interactive  environment 
with  immediate  computer  feedback  f.r  testing,  verifying,  and  fully  con¬ 
centrating  on  the  desired  editing  function. 

This  capability  has  been  achieved  by  implementing  an  on-line  test 
and  evaluation  package  that  serves  as  a  comprehensive  tool  for  edit,  table 
design  and  their  automatic  loading  to  the  system.  This  package  allows 
the  functional  verification  of  all  edit  tables  as  they  are  entered  into 
the  system.  It  displays  the  actual  processing  and  response  to  various 
classes  of  inputs  by  showing  in  detail  whether,  where,  and  why  a  table 
lets  correct  inputs  pass  while  incorrect  ones  are  rejected. 

The  interactive  software  of  the  Air  Facility  system  performs  the 
function  of  permitting  the  user  to  access  system  on-line  capabilities. 
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Basically  it  consists  of  a  sequence  of  displays  printed  at  the  Data- 
graphics  132B  terminal.  These  displays  request  information  from  the 
user  regarding  system  function  selection,  parameter  insertion,  data 
entry,  as  well  as  present  error  message  display  and  further  selection 
processing.  Responses  by  the  user  are  entered  by  depressing  the 
appropriate  key(s)  at  the  keyboard. 

To  perform  these  capabilities  the  following  software  modules  have 
been  implemented: 

a.  a  display  generator; 

b.  a  Character  Read/Echo  Module; 

c.  a  set  of  logical  error  check  modules;  and 

d.  an  Error  Communications  Display  Generator. 

Of  these  modules,  the  Display  Generator  and  the  Error  Communications 
Display  Generator  make  extensive  use  of  tables.  The  data  contained  in 
these  tables  implement  important  program  control  functions. 

The  Display  Generator  is  a  generalized  software  module  that  prints 
display  text  on  the  Datagraphix  terminal.  Its  major  capability  is  to 
be  able  to  print  any  text  stored  in  a  formatted  disk  file,  thus  separating 
text  from  a  source  program. 

The  Character  Read/Echo  Module  will,  as  titled,  read  and  echo  a 
character (s)  from  the  keyboard  to  the  Datagraphix  terminal.  The  module 
also  provides  cursor  positioning,  character  delete,  line  delete,  input 
escape,  and  no-echoing  of  excess  input  of  characters. 

The  logical  error  check  subroutines  determine  whether  the  user's 
inserted  characters  are  valid  with  respect  to  the  specific  application. 
Identified  error  checks  include: 


a. 

WAC  Validation; 

b. 

Installation  Validation; 

c. 

GEO-ID/Validation  Password; 

i 

d. 

Update  Format  Check; 

e. 

Update  Logic  Check;  and 

f. 

Positional  Parameter  Validation. 

1 

The  Error  Communications  Display  Generator  is  a  generalized 
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software  module  that  prints  error  messages  and  'Further 

Action1  prompts  on  the  Datagraphix  screen.  It  is  accessed 

when  a  user  inserts  an  invalid  response  to  a  prompt  or 

when  'shift  |  '  is  entered  in  character  input. 

The  on-line  capabilities  of  the  Air  Facilities  Subsystem  are 
supported  by  special  on-line  programs,  series  of  tables  with  software 
characteristics  in  function  areas  vital  to  the  user,  and  interactive 
modules  for  the  handling  of  basic  display  and  input  functions.  The 
special  on-line  software  is  outlined  in  greater  detail  in  the  following 
paragraphs.  It  provides  a  program  framework  that  enables  the  data  base 
management  functions  of: 

a.  System  Security  with  Log/on,  Log/off  procedures, 

GEO- ID/Password  checks,  and  their  correlations; 

b.  Data  Retrieval  from  the  AAFIF  data  base  and 
display  on  a  page-by-page,  group,  or  element 
level ; 

c.  Updates  with  extensive  format  and  logical  checks, 
including  automatic  updates  (computed  inputs) ;  and 

d.  Adds  and  Deletes  of  the  information  for  a  whole 
airfield. 

The  programs  for  the  on-line  data  base  management  system  consist 
of  the  following  modules. 

a.  AFF  -  Air  Facilities  Executive 


The  program  AFF  selves  as  the  on-line  Air  Facilities 
executive  and  perfo.-ms  the  functions  of  Log-on/Log-off. 
The  interactive,  on-line  mode  provides  for  a  full 
repertoire  of  error  checking  of  user- inserted  data  as 
well  as  a  complete  retinue  of  meaningful,  diagnostic 
error  messages  with  a  unique  steering  capability  to 
allow  the  user  to  act  upon  these  errors. 

The  program  initially  asks  the  user  to  enter  a  GEO-ID 
and  password.  These  values  serve  as  "keys"  to  enter 
the  program  which  then  accesses  a  subroutine  that  asks 
a  user  to  select  a  system  sanction.  The  functions 
include  ADD,  DELETE,  UPDATE,  DISPLAY,  RETRIEVE,  and 
LOG-OFF.  It  will  then  initiate  the  execution  of  the 
selected  function.  Upon  completion  the  user  will 
have  the  option  of  re-selecting  a  function. 
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1.  DISPLAY 

The  Display  Subroutines  permit  a  user  to  display 
and  view  selected  contents  of  an  Air  Facilities 
record.  The  program  initially  asks  the  user  to 
enter  the  WAC  and  installation  numbers.  These 
parameters  serve  to  identify  the  record  to  be 
displayed.  The  program  then  asks  the  user  to 
select  the  portion  of  the  record  that  is  to  be 
displayed.  The  full  record,  a  full  category, 
a  full  subcategory  of  a  category,  specific 
elements,  or  a  range  of  elements  may  be  chosen. 

2.  UPDATE 

The  Update  subroutines  permit  a  user  to  update 
selected  contents  of  an  Air  Facilities  record. 

The  program  initially  asks  the  user  to  enter 
the  WAC  and  installation  numbers.  These  para¬ 
meters  serve  to  identify  the  record  to  be  up¬ 
dated.  The  program  then  asks  the  user  to  select 
the  portion  of  the  record  that  is  to  be  updated. 

The  full  record,  a  full  category,  a  full  sub¬ 
category,  specific  elements,  or  a  range  of  elements 
may  be  chosen.  The  program  then  sequences  through 
the  selected  portion  of  the  record.  At  each  page 
the  present  contents  of  the  data  elements  are 
printed  and  the  user  simply  inserts  the  desired 
changes.  These  inputs  are  made  subject  to  format 
checks  with  corrective  actions  reouested  by  the 
system  when  necessary. 

Text  fields,  due  to  their  character  lengths,  are 
processed  following  the  regular  page  update.  Upon 
completion  of  this  process,  logical  checks  are  per¬ 
formed  that  correlate  the  entered,  new  data  with 
other  data  elements  of  the  airfield.  If  correct, 
the  update  process  will  be  completed  by  automatically 
writing  the  new  data  to  the  data  base.  Otherwise, 
the  user  will  be  notified  by  the  system  for  remedial 
actions.  Finally,  the  user  is  asked  if  another  record 
is  to  be  updated.  If  so,  the  above  described  process 
is  repeated. 

3.  ADD 

The  Add  Programs  permit  a  user  to  insert  or  add 
a  full  Air  Facilities  record  to  the  data  base. 

The  program  initially  asks  the  user  to  insert 
the  record  index  parameters  of  WAc,  installation 
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number,  and  coordinates.  The  program  then 
pages  through  each  page  of  elements  of  a 
subcategory  of  all  categories.  Due  to  their 
character  lengths,  text  fields  are  processed 
following  the  addition  of  regular  page 
element  fields.  Upon  completion  of  entering  a 
record  the  program  will  interactively  ask  if 
the  user  desires  to  enter  another  one.  If  so, 
the  above  described  process  is  repeated. 

4.  DELETE 

The  Delete  Subroutines  permit  a  user  to  delete 
an  Air  Facilities  data  record.  It  is  performed 
in  an  interactive,  on-line  mode.  It  provides 
for  a  full  repertoire  of  error  checking  of  user 
inserted  data  as  well  as  a  complete  retinue  of 
meaningful  diagnostic  error  messaoes  and  unique 
steering  capability  to  allow  the  user  to  act  upon 
these  errors. 

The  program  initially  asks  the  user  to  enter  WAC 
and  installation  numbers.  These  parameters  serve 
to  identify  the  record  to  be  deleted.  The  program 
then  asks  the  user  to  enter  or  delete  password. 

The  user  is  given  only  three  chances  to  correctly 
enter  the  password.  Then  the  record  is  deleted  and 
the  user  is  informed  via  a  display  of  such.  The  user 
may  also  delete  a  multiple  element  value;  the  field 
identifier  is  inserted  followed  by  the  multiple 
number. 

5.  RETRIEVE 

The  RETRIEVE  programs  permit  a  user  to  retrieve 
Air  Facility  records  according  to  user  specified 
parameters.  It  provides  for  a  full  repertoire  of 
error  checking  of  user  inserted  data  as  well  as 
a  complete  retinue  of  meaningful  diagnostic 
error  messages  and  a  unique  steering  capability 
to  allow  the  user  to  act  upon  these  errors. 

The  parameters  are  initially  a  table  that  creates 
a  Boolean  query  logic.  These  tables  are  then 
delimited  to  the  full  data  base,  a  geographic 
grid  area,  a  WAC  range,  country  range,  instal¬ 
lation  range,  or  list  of  previously  retrieved 
records.  The  program  then  will  retrieve  the 
records  and  pass  them  to  an  output  module. 
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b.  Error  Messages 


Two  types  of  error  messages  may  occur.  The  first 
is  contained  in  the  software  itself  and  triggered 
by  a  most  unusual  condition  tested  for  and  imple¬ 
mented  in  a  given  subroutine.  These  error  messages 
show  up  only  in  the  case  of  a  very  unusual  situation 
to  indicate  a  system,  table,  or  software  error. 

This  is  in  contrast  to  the  second  type  of  error 
messages  as  produced  by  the  Error  Communications 
Display  Generator.  The  latter  are  table  driven 
and  part  of  an  elaborate  Interactive  Communications 
Package  to  achieve  secure,  flexible,  and  fool  proof 
on-line  operations. 

The  first  type  of  error  is  program,  table,  or  system 
oriented  and  should  not  occur  at  all  in  an  operational 
system.  (If  it  does,  a  more  serious  problem  is  indicated, 
requiring  interventions  of  systems  people  or  programmers.) 
The  error  messages  are  of  the  general  form: 

***  XXXXXX 

with  'XXXXXX'  standing  for  a  specific  message  such  as 
'FORMAT  TABLE  MISSING.'  They  will  be  displayed  on  the 
screen  starting  at  the  current  cursor  position. 

The  second  type  of  error  is  user-oriented,  expected 
and  planned  for  to  provide  a  chance  for  pointing  out 
and  correcting  input  errors.  Depending  upon  function 
and  display  layout,  the  computer  generated  question 
is  sometimes  just  repeated  upon  receiving  an  invalid 
input. 

In  more  complex  situations  a  specific  error  message 
will  be  generated  and  shown  at  a  communications  con¬ 
trol  area,  along  with  the  options  available  to  con¬ 
tinue  processing.  The  user  need  only  enter  the  number 
that  corresponds  to  the  desired  choice  and  the  return 
key. 

c.  Security  Processing 

Using  the  log  on  provided  by  the  AOS  operating  system 
and  enhancing  its  capabilities  by  a  "Middle-Man"  filter 
program,  the  following  security  requirements  are  provided: 

1.  only  AIS  users  maintain  AAFIF  Data  Base; 
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2.  only  a  Data  Base  administrator  can  delete  airfields; 

3.  only  ADA  programmers  can  access  AOS; 

4.  all  others  have  "Read  Only"  access  limited  to 

their  area  of  interest;  and 

5.  the  Master  Console  operator  can  monitor: 

(a)  Terminal  Activity; 

(b)  Enable/Disable  Terminals;  and 

(c)  Change  Terminal  Usage  Priorities. 

2. 3. 2. 4. 2  Data  Dictionary.  The  AAFIF  Data  Dictionary  provides 
interactive  entry  and  viewing  of  air  field  data  elements  for  the  data 
base  administrator.  This  function  is  the  controlling  mechanism  of  the 
data  base  content  and  structure. 

The  Data  Dictionary  provides  a  way  to  define  and  manage  Air  Facility 
information.  Its  objectives  are: 

a.  define  and  store  AAFIF  element  information  on  a 
schema/subschema  level;  and 

b.  provide  for  evolving  AAFIF  data  content  and  editing 
via  a  data  base  language  that  consists  of  menu- 
oriented  interactive  software. 

In  order  to  obtain  a  high  level,  logical  view  of  the  data  base,  a 
series  of  menus  and  CRT  displays  are  used  in  creating  a  DBL  (Data  Base 
Language) .  The  task  of  the  DBL  is  to  convey,  in  a  simple  straight 
forward  manner,  the  data  base  configuration.  For  example,  if  the  data 
base  administrator  wanted  to  see  the  U.  S.  airfield  configuration,  all 
the  inter-related  elements  that  comprised  it  would  be  displayed. 

Other  information  and  processing  that  the  DBL  provides  are: 

a.  a  method  to  review  data  subcategories  showing  element 
name,  description,  number  of  characters,  multiple,  etc., 
etc.  This  provides  an  interactive  data  base  definition 
analogous  to  APPENDIX  C  in  the  system  documentation; 

b.  a  method  to  review  data  inter-dependencies,  and  edits, 
and  to  change  them;  and 

c.  a  method  to  add,  modify  or  delete  data  elements 
(logical  element  configuration) . 


There  are  two  major  files  used  by  the  Data  Dictionary.  The  first 
file  is  a  Data  Configuration  File.  It  contains: 

a.  element  name  (i.e.,  GLol) ; 

b.  element  description; 

c.  element  size; 

d.  computed  value  indicator; 

e.  multiple  indicator; 

f.  maximum  number  of  multiples;  and 

g.  card  code. 

It  is  used  and  is  maintained  for  the  purpose  of  reviewing  and  logically 
manipulating  data  elements. 

The  second  file  maintained  is  the  COBOL  File  Description  Library. 
Each  AAFIF  subcategory  has  its  own  library  member.  An  example  of  this 
is  shown  below. 

01  AT-SUB-CATEGORY 

05  AT11  PIC  X  (620) 

05  AT12  PIC  XXX 

05  AT-MULT-OCCURRENCE  PIC  99 

05  AT -MULTIPLES  OCCURS  1  TO  11  TIMES  DEPENDING  ON  AT-MULT 

OCCURRENCE . 


10 

AT01 

PIC 

XXX 

10 

AT02 

PIC 

X 

10 

AT03 

PIC 

XXX 

10 

AT04 

PIC 

XXX 

10 

AT05 

PIC 

X 

10 

AT06 

PIC 

xxxx 

10 

AT07 

PIC 

X  (6) 

10 

AT08 

PIC 

XXX 

10 

AT09 

PIC 

X 

10 

AT10 

PIC 

XXX 

a.  Application  Programs 

The  Application  Programs  usually  involve  the  processing  of 
larger  sections  of  the  data  base.  For  that  reason  a  'whole¬ 
sale'  off-line  processing  during  the  off  hours  (nights, 
weekends,  holidays)  is  indicated.  Nevertheless,  the  on-line 
system  is  frequently  used  to  initiate  and  to  simplify  those 


off-line  procedures  (e.g. ,  the  on-line  creation  of 
Boolean  search  tables  for  the  off-line  processing 
of  large  SAIR  requests) . 

The  system  output  products  are: 

1.  CRT  displays  of  AAFIF  content  for  analyst's 
review  (local  and  remote) ; 

2.  extracted  subsets  (key  files)  of  the  AAFIF  Data 
Base  (these  are  used  by  application  software) ; 

3 .  SAIR/DAIR/184  Reports ; 

4.  special  and  scheduled  tape  and  printed  report 
products  from  the  AAFIF  Data  Base:  and 

5.  ASSOTW/EBR  Tapes  for  input  to  the  Charting 
Subsystem. 

The  batch  process  functions  of  this  system  provide  the 
output  tape  and  hardcopy  products.  Due  to  the  nature  of 
the  interactive  software,  all  of  the  U1108  processing 
is  either  obsolete  or  modified  in  its  data  gathering 
methods. 

The  primary  reasons  for  this  software  streamlining  are 
two  fold.  First,  a  transaction  activity  log  is  main¬ 
tained  on  disk  in  ascending  date-time  sequence.  This 
allows  the  extraction  of  data  base  changes  for  any  period 
of  time  (i.e.,  2  days,  3  weeks,  1  month,  etc.,  etc.).  This 
file  is  used  to  produce  WWMCCS,  DIA,  etc.  output  tapes. 

Secondly,  the  ASSOTW  production  will  become  more  auto¬ 
matic  and  controlled  by  the  AIS.  As  an  integral  part 
of  the  data  base,  an  indicator  is  maintained  to  mark 
all  data  elements  that  changed  along  with  a  counter 
(displayed  to  the  analyst)  showing  how  many  elements 
have  changed  since  the  last  ASSOTW  publication.  This 
provides  the  analyst  with  information  to  be  used  to 
make  a  judgement  decision  on  when  an  ASSOTW  is  issued. 

The  ASSOTW  log  file  is  automatically  maintained  to  mark 
those  airfield  records  adjudged  by  the  AIS  to  have  ASSOTW 
significant  changes.  The  ASSOTW  applications  program  utilizes 
the  ASSOTW  log  to  determine  which  airfields  are  to  be  reported 
in  the  requested  ASSOTW  volume  and  to  which  section  or  index  the 
applicable  airfield  information  belongs. 

Boolean  Retrieval 

The  use  of  this  function  is  depicted  in  the  following  scenario. 


First,  the  ADA  programmer  envokes  the  software  from 
a  CRT;  the  existing  logic  tables  are  then  reviewed. 

At  this  point,  the  user  can  refine  an  existing  table 
or  create  a  new  one.  The  table  is  then  "ran"  against 
the  data  base  in  a  batch  mode.  Depending  on  the  results 
of  the  search,  the  user  can  either  refine  this  table  or 
continue  with  the  next  step.  The  extract  file  is  then 
used  as  input  to  a  batch  application  program  that  reads 
the  data  base  and  writes  tapes  or  printed  reports.  An 
optional  intermediate  step  can  be  included  that  sorts 
a  user-specified  field  that  is  included  in  the  extract 
file.  For  example,  if  a  report  is  desired  in  alphabetica 
order  by  airfield  name,  those  element (s)  to  be  included 
would  be  specified  on  the  extract  file. 

FORTRAN  Interface 

The  interactive  software  (FORTRAN)  required  an  interface 
to  be  provided  to  support  blocked  data  base  records  with 
INFOS  structure  independance .  The  main  functions  of 
this  additional  software  is  to: 

1.  provide  subroutines  to  replace  the  existing 
(PILOT  software)  INFOS  manipulation  loqic; 

2.  return  to  calling  program  individual  data 
elements; 

3.  provide  the  ability  to  decipher  the  data 
map  associated  with  each  variable  length 
data  base  record. 

4.  interface  with  the  PILOT  interactive  software 
in  such  a  way  as  to  minimize  any  changes;  and 

5.  provide  the  "Hooks  and  Handles"  to  change  the 
INFOS  data  base  structure  at  any  time  with  no 
impact  on  the  interactive  processing. 

COBOL  Interface 

In  order  to  support  COBOL  in  an  effective  manner, 
and  to  provide  data  element  name  continuity,  an 
interface  is  provided.  The  subcategory  record  lay¬ 
outs  that  are  created  and  maintained  by  ADA  programmers 
are  used  along  with  a  Synectics-supplied  COBOL  module 
to  support  this  feature.  Its  main  function  is  to  allow 
application  programs  to  access  the  data  base  and  acauire 
an  entire  subcategory's  data  elements  at  one  time.  An 
area  of  working  storage  (in  a  COBOL  program)  is  defined 
'as  large  as  the  largest  subcategory  to  be  accessed. ' 


This  area  is  then  redefined  using  the  included 
(COPYLIB)  record  layouts.  It  is  then  a  simple 
matter  of  calling  the  interface  module  to  read 
a  subcategory.  The  calling  sequence  consists  of 
passing  the  subcategory  code  to  be  accessed  and 
the  group  level  name  of  the  COPYLIB  record  for 
that  subcategory  to  the  subroutine. 

e.  Data  Base  Reconfiguration 


In  the  process  of  adding,  changing,  or  deleting 
data  elements  (on  a  schema/subschema  level) ,  it 
periodically  becomes  necessary  to  change  the 
physical  layout  of  the  data  base.  After  the  logical 
definition  and  manipulation  is  completed  (using  the 
interactive  Data  Dictionary) ,  this  system  function  is 
utilized.  The  actions  performed  by  this  process  in¬ 
clude  changing  every  airfield  that  has  the  modified 
data  elements  and  ADA  programmers  changing  the  appropriate 
COBOL  COPYLIB  record  descriptions.  Because  of  the 
nature  of  these  operations,  this  function  executes  in 
a  batch  environment  and  requires  exclusive  use  of  the 
M-600  system. 

f .  Transaction  Activity  Log/AIS  Activity  Report 

In  order  to  provide  management  control  and  an 
information  audit  trail  mechanism,  a  transaction 
activity  log  is  maintained  by  the  software  that 
can  report  system  use  for  activity  history  and 
analysis.  The  report  provided  in  the  PHASE-II 
design  is  the  AIS  report.  This  report  is  pro¬ 
duced  daily  and  is  used  to  visually  verify  the 
previous  day's  transactions  (by  the  AIS).  It  is 
sorted  and  paginated  in  such  a  way  that  it  can 
be  decollated  and  each  AIS  will  get  an  individual 
report.  The  information  on  the  report  is: 

1.  AIS  analyst  code; 

2.  identification  information  for  airfield; 

3.  any  change  to  a  subcategory  will  produce  a  print 
of  the  entire  subcategory; 

4.  data  content  before  change; 

5.  data  content  after  change;  and 

6.  date  and  time  change  made. 
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2.3.3  Charting 

The  Charting  Subsystem  of  the  Automated  Air  Information  Production 
System  (AAIPS)  is  tasked  with  the  capture,  revision,  and  output  of  graphic 
data  appearing  throughout  the  DMAAC  Flight  Information  Publications 
(FLIPs).  Consistent  with  the  time-saving  purpose  of  all  three  subsystems, 
the  Charting  Subsystem  achieves  its  goal  by  the  preservation  of  data  in 
digital  form  and  providing  techniques  to  effect  the  simplicity  of  alter¬ 
ation  of  the  data. 

The  subsystem  is  required  to  support  the  creation  and  maintenance 
of  a  FLIP  graphic  data  base  which  is  further  exploited  to  generate  other 
FLIP  products.  The  Charting  Subsystem  also  accepts  data  from  the  Pub¬ 
lishing  and  Air  Facilities  Subsystems,  merges  charting  data  with  textual 
data  from  the  Publishing  Subsystem,  and  generates  film  positives  throuqh 
the  Electron  Beam  Recorder  (EBR) . 

The  subsystem  provides  interactive  data  acquisition/revision,  EBR 
data  processing,  EBR  control  processing/recording,  EBR  symbol/text 
library  maintenance,  charting  data  base  maintenance,  and  EBR  graphic 
data  base  maintenance.  The  three  major  functional  areas  are:  Interactive 
Data  Acquisition,  EBR  Data  Preparation,  and  EBR  Control  Processing. 

Reference  Figure  2-16. 

The  Charting  Subsystem  is  designed  and  implemented  in  a  functionally 
modular  fashion  with  each  operation  performed  having  a  very  discrete  re¬ 
sult.  Well  defined  functions  are  implemented  which,  under  operator  control, 
can  be  linked  together  to  accomplish  very  complex  digitizing  or  editinq 
functions.  The  system  is  menu-driven  with  the  menu  containing  thirteen 
(13)  functional  capabilities  which  are  divided  into  162  subfunctions  or 
operations . 


2. 3. 3.1  Capabilities 

In  the  Charting  Subsystem  the  following  capabilities  are  available: 

a.  A  digitization  capability  that  will  permit  a  smooth 
finished  quality  graphic  to  be  produced  from  a 
rough  hand  drawn  sketch.  An  operator  may  perform 
the  following  operations: 

1.  define  a  single  line  between  two  points  at 
a  scale  determined  by  the  operator; 

2.  trace  free  form  lines  while  the  system  records 
the  line  points; 

3.  construct  lines,  arcs,  and  circles  as  dots,  dashes,  or 
solid  lines,- 
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CHARTING  SUBSYSTEM 
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-16.  Charting  Subsystem  Functions 


4.  designate  one  or  multiple  straiqhf-  lin*  •  : 
by  digitizing  only  the  end  points; 

5.  intermix  straight  line  segment---  .m  :  •;  >  • 
to  define  a  complete  featurc; 

6.  digitize  a  rectangle  by  enterinq  fh.  J :  , 
opposite  corners; 

7.  digitize  a  circle  by  either  enterinq  •• 
and  a  point  on  the  circumference  r  I  \  •  •  • 
any  three  points  on  the  circumference 

8.  digitize  an  arc  by  enterinq  the  end  :> 
the  arc  and  entering  its  center 
entering  a  midpoint  on  the  arc;  i 

9.  smooth  the  display  of  arcs  and  cirri'-  !  . 
increasing  the  number  of  displayed  poi**  . 

The  capability  to  edit  graphics  that  were  previ 
digitized.  The  types  of  changes  include  delete,  h 
or  add  more  lines,  symbols,  text,  or  entire  drawino 
Edits  may  be  invoked  by  menu  at  the  digitizer  and  i 
elude  the  following  operations: 

1.  delete  all  data  in  sections  outside  a 
designated  area; 

2.  define  and  make  location  changes  to  points 
on  a  line; 

3.  define  and  move  text  and  symbols; 

4.  define  and  simultaneously  move  all  lines, 
points,  text,  and  symbols  in  a  designated 
area  to  a  new  area; 

5.  move  any  and  all  points; 

6.  any  previously  digitized  point  may  be 
found  by  the  operator  indicating  the 
approximate  location  of  the  desired 
data  and  the  system  will  perform  the 
search  over  the  entire  format  or  to  an 
operator  devised  area  of  interest;  and 

7.  apply  curve  smoothing  by  presetting  the 
smoothing  threshold  to  the  desired  value. 
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c.  Registration  of  a  drawing  (if  not  aligned  with 
absolute  coordinate  frame)  by  indicating  control 
points.  The  system  automatically  generates 
coordinate  transformation  coefficients  for  each 
registered  drawing.  All  digitizing  coordinate 
values  are  transformed  by  these  coefficients 
until  they  are  implicitly  changed  by  a  new 
registration.  The  coordinate  transformations 
correct  for  scale,  translation,  and  rotation. 

The  ability  to  digitize  the  drawing  origin  if 
different  from  the  digitizer  origin.  The  coordinate 
frame  for  all  data  in  the  drawing  file  is  relative 
to  the  drawing  origin  rather  than  the  absolute 
origin  and  the  absolute  coordinate  frame. 

*.  The  ability  to  select  the  recording  resolution  by 
allowing  different  levels  of  grid  spacing. 

f.  A  graphic  display  capability  to  permit  the  operator 
to  display  the  contents  of  either  the  drawing  or 
scratch  file.  The  current  image  of  the  original 
drawing  remains  on  the  screen  (despite  new  changes) 
until  the  erase  control  mechanism  is  activated 
which  clears  the  display  screen.  The  operator 

may  select  any  retangular  area  within  the  regis¬ 
tered  drawing  file  by  cursor  pointing  and  the 
area  is  brought  into  view  on  the  display  scaled 
to  span  the  whole  screen  area.  Alternatively,  the 
operator  may  indicate  a  single  point  and  the 
neighborhood  of  the  point  will  be  displayed  on  the 
screen  at  drawing  scale. 

g.  An  efficient  text  entry  and  placement  capability 
by  utilizing  the  digitizer  for  positioning  and 
the  keyboard  for  text  entry  which  includes  the 
following  capabilities: 

1.  the  size  of  the  text  may  be  varied 
explicitly  through  a  keyboard  entry; 

2 .  the  text  string  may  be  rotated  through 
+  360°; 

3.  for  symbols  containing  variable  text,  the 
system  requests  the  operator  to  enter  the 
text,  which  is  then  positioned  within  the 
symbol  at  the  proper  relative  position;  and 
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4.  the  display  of  text  over  the  whole  screen  is 
operator  selectable;  the  text  display  is 
disabled  automatically  if  the  drawing  scale 
renders  t:he  text  unreadable. 

h.  Efficient  symbology  creation,  selection,  and 
placement  which  includes  the  following  capabilities: 

1.  support  a  symbol  file  of  up  to  500  symbols 
and  permit  selection  of  any  symbol  for  place¬ 
ment; 

2.  digitize  finished  quality  symbols  for  the 
operator's  own  user  symbol  file  without 
disturbing  the  drawing  file; 

3.  vary  the  symbol  scale  by  operator  selection; 

4.  rotate  symbol  through  +  360°; 

5.  generate  mirror  imaqes  of  symbols  about 
the  vertical  axis; 

6.  provide  five  levels  of  nesting  for  creation 

of  new  symbols  which  contain  other  symbols;  and 

7.  allow  a  symbol  to  be  repeated  between  any  two 
points  on/or  along  area  boundaries  or  circum¬ 
ferences  o’  circles  automatically. 

i.  A  flexible  and  efficient  file  management  mechanism 
which  permits  the  operator  to  have  simultaneous  access 
to  three  files  (drawing,  scratch,  and  symbol)  at  all 
times.  The  drawing  file  is  the  repository  for  the 
drawing  that  is  currently  being  manipulated.  The 
scratch  file  is  the  repository  for  a  new  or  temporary 
symbol,  while  permitting  data  in  the  main  drawing 
file  to  be  undisturbed.  A  symbol  file  can  contain 

a  maximum  of  500  symbols  (300  standard  and  200  user 
symbols) .  The  following  file  handling  capabilities 
are  provided: 

1.  segregate  drawings  into  layers  (subfiles)  up 
to  a  maximum  of  32  separations; 

2.  select  a  new  drawing  or  symbol  file  at  any 
time; 

3.  selectively  display  the  contents  of  the  drawing 
or  scratch  file,- 
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4. 


clear  the  contents  of  the  drawing  or  scratch 
file; 

5.  convert  the  contents  of  the  drawing  file  or 
scratch  file  into  a  symbol  and  store  it  into 
the  symbol  file; 

6.  retrieve  a  symbol  to  the  drawing  or  scratch 
file  for  modification; 

7.  generate  on  the  hardcopy  unit  a  list  of  coordinates 
and  status  of  all  arcs,  lines,  circles,  and  text 
for  the  drawing,  scratch,  and  symbol  files;  and 

8.  permit  a  new  drawing  to  be  digitized  while  another 
drawing  is  being  output  to  the  Charting  Subsystem 
output  device. 

j .  Output  processing  that  can  search  the  Charting 
Subsystem  data  base  at  product  cut  off  time  and 
retrieve  only  those  files  that  have  been  revised 
since  the  last  product  cut  off.  For  each  chart 
retrieved,  a  hardcopy  printout  consisting  of  the 
chart  identification,  total  number  of  revisions, 
and  number  of  revisions  for  each  color  separation 
is  provided. 

k.  A  final  output  capability  via  the  Charting  Sub¬ 
system  output  dc.  ice  which  produces  final  com¬ 
posite  ready-for-production  film  negatives  as 
follows : 

1.  accepts  formatted  magnetic  tape  data  files 
from  the  Publishing  and  Air  Facilities 
Subsystems  to  produce  textual  output; 

2.  produces  graphic  output  prepared  by  the 
Charting  Subsystem;  and 

3.  merges  data  from  the  Charting  and  Publishing 
Subsystems  to  produce  combined  text  and 
graphic  outputs,  in  which  the  text  and  graphics 
may  be  either  side  by  side  on  a  page  or  on 
entirely  separate  pages. 

l.  A  restricted  access  log-on  procedure  to  assure 
only  authorized  use  of  the  digitization  stations. 


2-67 


2. 3. 3. 2  Design  Criteria 

Ihe  primary,  controlling  precept  in  the  design  of  the  Charting 
Subsystem  was  that  it  must  support  the  acquisition,  modification,  and 
output  of  any  and  all  graphic  image  data  occurring  throughout  the  spec¬ 
trum  of  FLIP  publications.  While  many  of  the  FLIP  products  are  or  can 
be  treated  as  pure  graphics  (and  therefore  handled  entirely  within  the 
Charting  Subsystem) ,  several  of  the  document  types  are  primarily  textual 
and  must  be  processed  by  special  techniques  in  the  Publishing  Subsystem. 
This  situation  then  created  the  additional  Charting  design  requirement 
that  a  data  and  procedural  interface  be  established  to  merge  components 
from  two  widely  dissimilar  data  bases.  The  solution  derived  was  to  have 
the  Publishing  Subsystem  be  the  controlling  process,  calling  for  graphic 
inserts  (previously  created  by  Charting  and  residing  in  the  Charting  data 
base  in  EBR  tape  format)  to  be  merged  with  Publishing  text  which  has  also 
been  converted  to  EBR  tape  format.  The  possibility  of  adding  a  second 
tape  drive  to  the  EBR  PDP-11  controller  and  modifying  the  controlling 
software  to  combine  the  two  data  sources  in  real  time  was  rejected  be¬ 
cause  of  the  difficulties  of  maintaining  the  proper  sequence  and  synchro¬ 
nization  of  data  from  two  subsystems  which  act  independently  until 
data-merge  time.  In  the  method  used,  Charting  data  may  be  retrieved 
randomly  from  the  disk  unit  so  that  the  order  dictated  by  the  Publishing 
tape  at  run  time  is  accomplished.  In  the  event  that  a  requested  graphic 
does  not  exist  in  the  Charting  data  base,  a  default  "empty  box"  is  sub¬ 
stituted. 

The  second  major  design  criteria  was  that  the  Charting  Subsystem  must 
be  capable  of  supporting  the  full  production  work  load  with  a  minimum 
replication  of  hardware  (beyond  the  Pilot  configuration)  while  supporting 
subsidiary  processes  with  any  system  resources  (memory,  disk  space,  etc.) 
not  required  by  the  principal  function  of  graphic  data  capture  and  re¬ 
vision.  Also,  execution  of  subsidiary  processes  must  not  noticeably 
degrade  the  principal  function  by  causing  the  graphic-compiler/operator 
to  wait  for  service  any  more  than  if  the  subsidiary  function  was  not 
executing. 

2. 3. 3. 3  Subsystem  Data  Base 

The  Charting  subsystem  Data  Base  exists  in  two  distinct  forms, 
namely: 

a.  the  set  of  files  cn  disk  packs  containing 
chart  imagery  or  supporting  the  acquisition 
or  revision  of  chart  imagery;  and 

b.  a  library  of  magnetic  tapes  in  the  Electron  Beam 
Recorder  drive  format  containing  chart  data  current 

to  the  last  previous  publication  data  for  each  product 
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type.  This  library  exists  solely  to  avoid 
re-conversion  of  data  (to  EBR  format)  which 
has  not  changed  since  the  last  publication 
cycle  of  a  product. 

Only  the  general  structure  and  use  of  these  files  will  be  given 
in  this  document  since  the  details  on  record  formats  and  content  are 
discussed  fully  in  the  Programmer  User's  Manual  for  the  Charting  Sub¬ 
system.  Except  as  noted,  all  disk  files  are  random  access,  variable- 
length  logical  records,  accessed  by  physical  block  of  S12  bytes. 

2. 3. 3. 3.1  Digitizing/Editing  station  disk  files.  Physical  disk 
space  is  logically  divided  into  a  variable  number  of  sub-areas  known  as 
directories.  The  primary  directory  (DZO)  holds  several  utility  files 
which  are  used  for  all  types  of  products,  while  the  sub-directories 
each  contain  files  pertaining  only  to  a  single  product  type  (e.g.,  low 
enroute,  high  IAP,  general  planning,  etc.).  The  subsystem  structure 
supports  the  addition  of  any  number  of  sub-directories  and  each  sub¬ 
directory  can  expand  or  contract  as  required,  limited  only  by  the  total 
disk  capacity  of  192  M  Bytes.  The  types  of  data  files  used  are  listed 
below. 

a.  Drawing  Files 

These  are  random  access  files  located  within  sub¬ 
directories,  each  of  which  comprise  a  single  graphic 
entity  such  as  one  SID,  one  chartlet  for  the  VFR 
Supplement,  one  side  of  an  enroute  chart  and  so  forth. 

The  first  physical  record  (Block  0)  is  a  fixed- 
length  parameter  record  which  maintains  informa¬ 
tion  pertaining  to  the  digitization/editing  process 
(chart  origin  coordinates,  registration  co-efficients, 
selected  line  weight,  selected  symbol  number,  etc.) 
such  that  a  work  session  on  the  drawing  may  be 
interrupted  temporarily  and  resumed  later  with  all 
conditions  established  by  the  operator  remaining 
intact.  All  subsequent  records  (Blocks  1  through  n) 
contain  logical  descriptors  of  features,  variable 
in  length,  in  six  classes. 


1 .  PATH 

2.  AREA 
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3.  FIXED  TEXT 


4 .  VARIABLE  TEXT 


5.  STANDARD  SYMBOL  REFERENCE 

6.  USER  SYMBOL  REFERENCE 

PATH  and  AREA  (boundary)  data  are  both  lineal  in 
nature;  composed  of  absolute  coordinate  points, 
vector  strings,  or  arc/circle  specifiers,  all  of 
which  may  be  intermixed.  Vector  data  is  generally 
acquired  by  tracing  features  of  a  complex  character. 

FIXED  TEXT  and  VARIABLE  TEXT  (the  latter  is  used 
only  with  USER  SYMBOLS)  record  types  specify 
characteristics  of  a  string  of  text:  position,  angular 
orientation,  justification  (horizontal  and  vertical), 
color/screen,  and  font  style.  Four  font  styles  are 
available,  but  a  maximum  of  254  may  be  accommodated. 
Multiple-line  strings  are  handled  automatically  by 
stepping  along  the  normal  to  the  base-line  angle 
each  time  a  carriage-return  character  is  found  in 
the  text  string. 

USER  SYMBOL  and  STANDARD  SYMBOL  reference  records 
are  similar  except  that  a  User  Symbol  reference  may 
contain  a  Standard  Symbol  reference  but  not  vice  versa. 
Both  call  for  the  placement  of  a  predefined  "mini¬ 
drawing"  within  the  final  (film)  image  at  a  point, 
along  a  path,  or  filling  an  area. 

Revision  Index  Files 


One  Revision  Index  file  exists  in  each  product 
directory.  They  are  random  access  files,  blocked 
32  words  per  logical  record.  Each  record  contains 
the  name  of  one  drawing  file  in  the  product  directory, 
a  single-word  "bit  map"  of  which  color/screen  groups 
in  the  drawing  have  been  edited  or  added  to  since 
the  last  previous  publication  cycle,  a  cumulative  time 
(minutes)  expended  creating  or  editing  the  particular 
drawing,  and  a  cumulative  count  of  revisions  performed. 
Also,  if  the  drawing  is  not  one  which  has  been  newly 
created  since  the  last  publication  date,  the  logical 
record  also  carries  the  magnetic  tape  reel  number  (on 
which  the  EBR-format  data  is  stored)  and  a  list  of 
"image  numbers"  (file  numbers)  of  the  various  color/ 
screen  separations  within  the  tape.  Whenever  a  new 
publication  cycle  is  run,  the  reel  number  and  image 
number  list  is  updated  appropriately  and  all  bits  in 


the  C/S  bit  map  word  are  cleared  indicating  that 
the  archival  tape  contains  the  latest  information. 
Further  editing  of  any  part  of  a  drawing  again 
sets  bits  in  this  word  such  that  the  next  run 
will  re-process  the  changed  portions. 

c.  Symbol  Files 

These  files  reside  within  the  sub-directory  USYMB 
and  are  collections  of  "mini-drawings"  in  the  same 
data  format  as  described  for  the  main  drawing  files 
except  that  the  first  block  is  an  index  correlating  a 
particular  symbol  number  to  a  disk  address.  Their  pur¬ 
pose  for  standard  symbols  is  solely  the  displaying  of 
an  approximate  representation  of  a  pre-de fined  image 
on  the  operator's  terminal,  since  later  creation  of 
the  film  image  on  the  EBR  uses  only  the  symbol  number 
(stored  in  a  symbol  reference  record  in  the  main 
drawing  file)  to  access  a  library  of  precision  images 
stored  on  the  EBR/PDP-11  disk  units.  However,  since 
the  operator  has  the  capability  to  create  compound 
"user  symbols"  incorporating  both  standard  symbols 
and  other  linework  for  repititive  recall,  the  ability 
to  create  personal  symbol  files  (stored  in  the  same 
USYMB  directory)  to  retain  such  work  for  subsequent 
editing/digitizing  sessions  is  also  given.  Each 
symbol  file  may  contain  300  standard  symbols  and 
200  compound  user  symbols;  there  is  no  limit  on  the 
number  of  symbol  files  residing  in  USYMB  except  total 
disk  space. 

d.  Log  File 

This  file  is  used  only  for  logging  onto  the  subsystem 
and  gaining  access  to  files;  not  for  identifying  any 
link  between  data  files  and  a  particular  operator  or 
group,  or  for  establishing  any  sort  of  system  security. 

e.  Message  File 

This  is  simply  an  external  list  of  most  of  the  error 
messages  and  help  prompts  used  in  the  subsystem.  Use 
of  an  external  file  instead  of  embedding  messages  with¬ 
in  subroutines  allows  easy  modification  of  formats  and 
use  of  any  message  by  multiple  program  modules. 

f.  Grid  Area  Index  File 


To  accommodate  rapid  editing  access  to  any  particular 
feature,  this  file  is  a  tabulation  of  disk  address 
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for  feature  lines  passing  through  each  of  10080  grid 
areas  (120  columns  x  84  rows,  one  half  inch  spacing  in 
both  dimensions) .  The  file  is  blocked  at  15  words  per 
logical  record,  to  allow  seven  (7)  block/word  address 
pairs  for  each  grid  area,  plus  an  overflow  link  in  case 
more  than  seven  (7)  features  pass  through  any  grid 
square.  Overflow  records  are  also  15  words  long,  so 
that  a  grid  containing  parts  of  more  than  14  features 
would  overflow  to  a  third  record  and  so  on.  Typically, 
few  grids  contain  more  than  seven  (7)  features  and 
therefore,  each  usually  requires  only  one  block. 

When  an  operator  initiates  a  search  for  a  feature  (for 
editing)  the  coordinate  location  of  the  cursor  establishes 
the  grid  area  and  therefore  the  chain  of  index  blocks  to  be 
used  for  candidate  features.  Each  feature  is  examined  in 
detail  for  a  match  to  a  color/layer  mask  and  search  toler¬ 
ance  (distance)  established  by  the  operator;  any  feature 
meeting  these  criteria  are  listed  on  the  station  Dasher 
terminal  (parameters  and  x,  y  coordinates)  until  aborted 
by  the  operator. 

g.  Font  Files 


Similar  in  use  and  structure  to  the  symbol  files, 
these  font  files  exist  only  for  the  digitizer 
operator's  display  terminal  presentation  of  alpha¬ 
numeric  strings  in  approximate  proper  size,  style, 
and  orientation.  A  total  of  254  font  or  symbol 
files  may  be  employed  by  the  subsystem.  Each  font 
file  may  contain  up  to  128  characters. 

2. 3. 3. 3. 2  Electron  Beam  Recorder  Tape  Library.  This  library 
is  maintained  to  avoid  the  reprocessing  of  graphic  data  which  has  not 
been  altered  since  the  last  publication  of  a  product.  Each  graphic 
entity  which  is  to  appear  on  a  separate  film  image  comprises  one  tape 
file.  All  records  in  the  file  are  fixed  at  2048  words  in  length  except 
the  last,  which  may  be  as  short  as  necessary.  The  first  three  (3)  words 
of  each  record  are  control  words  identifying  image  number  (file  number), 
page  number  (a  selectable  subset  of  an  image) ,  and  record  number  (within 
the  page) .  The  remaining  words  in  each  record  fall  into  two  (2)  categories. 

a.  Command  words 


1.  Set  beam  intensity  (64  steps) 

2.  Set  line  weight  (6  microns  to  6138 
microns,  1023  steps) 

3.  Set  font  number 
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4.  Set  character  size 


5.  Set  character  (string)  angle 

6.  Enter  ASCII  mode 

7.  Enter  Incremental  Vector  Plot  mode 
(not  used  in  Pilot  system) 

8.  Enter  Vector  mode 

9.  Set  Point  x  &  y  (Move  with  beam  off 
to  new  absolute  position) 

10.  Relative  move  x  &  y  (with  beam  on) 
b.  Data  strings 

1.  ASCII  characters,  two  per  word,  output 
under  conditions  established  by  command 
words . 

2.  Incremental  Vector  steps,  four  per  word, 

six  micron  steps  in  eight  possible  directions 
(not  used  in  Pilot  system) . 

Note  that  standard  symbols  are  ASCII  characters 
within  Font  1 ,  and  that  additional  fonts  may  be 
established  if  the  need  arises. 

2. 3. 3.4  Subsystem  Software 

The  Charting  Subsystem  software  consists  of  three  (3)  packages  to 
perform: 

a.  interactive  graphic  data  acquisition  and  revision; 

b.  conversion  of  graphic  data  to  Electron  Beam 
Recorder  drive  tape  format;  and 

c.  merging  of  graphic  data  with  Publishing 
Subsystem  textual  data  to  produce  a  single 
EBR  drive  tape. 

2. 3. 3. 4.1  Interactive  Graphic  Software.  The  first  of  these 
packages,  for  interactive  graphic  manipulation,  consists  of  a  main 
(executive)  routine  and  88  subroutines  (organized  functionally  into  23 
overlay  modules)  and  one  group  of  core-resident  utility  routines.  De¬ 
tailed  documentation  and  flowcharts  for  all  subroutines  can  be  found 


in  the  subsystem  Programmer's  Manual,  and  will  not  be  repeated  here. 
The  major  functions  of  the  24  groups  are  as  follows: 

a.  Executive  module  accomplishes: 

1.  digitizing  table  servicing  including  recognition 
and  interpretation  of  cursor  keys  and  cursor  x,  y 
position; 

2.  correlation  of  cursor  key /position  to  desired 
function ;  and 

3.  overlay  module  load  and  call  (execute)  . 

b.  Log-On  module: 

1.  accepts  User  identification  and  password 
character  strings;  and 

2.  verifies  legitimate  identifiers  or  aborts 
station  initialization. 

c.  Directory/File  Initialization  module: 

1.  accepts  directory  (product  type)  name, 
file  (drawing)  name,  and  symbol  file  name; 

2.  if  directory  and  file  named  exist,  copies 
that  file  to  a  temporary  (working)  version 
and  builds  a  grid  area  feature  index;  and 

3.  if  directory  and/or  file  do  not  exist  (and 
operator  confirms  that  new  desired)  establishes 
new  symbol  file  with  no  content. 

d.  Registration  control  module  functions: 

1.  menu  origin  select; 

2.  chart  origin  select; 

3.  registration  correction  computation;  and 

4.  registration  verification. 

e.  Resolution  control  module: 

1.  establishes  grid  round-off  and  trace 
resolution  spacing. 


f.  Path  type  control  module: 

1.  line  type  select;  and 

2.  line  thickness  select. 

g.  Shading  control  module: 

1.  area,  text,  path,  and  symbol  shading  select. 

h.  Text  type  control  module : 

1.  font  style  select; 

2.  variable  text  on/off  select; 

3.  font  size  select;  and 

4.  horizontal  &  vertical  justification  select. 

i.  Text  rotation  control  module: 

1.  0°,  +90°,  or  -90°  rotation  select; 

2.  manual  rotation  select  (any  angle) ;  and 

3.  analog  rotation  select  (any  angle) . 

j.  Symbol  rotation  control  module-. 

1.  0°,  Manual,  or  Analog  rotation  select. 

k.  Symbol  type  control  module: 

1.  symbol  scale  select;  and 

2.  mirror  on/off  select. 

l.  Edit  control  (three  overlay  modules); 

1.  layer/separation  select; 

2.  search  tolerance  select; 

3.  locate  feature; 

4.  display  and  list  feature; 

5.  modify  feature  header; 
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6.  delete  feature/text; 

7 .  move  text ; 

8.  move  point  symbol; 

9.  delete  point  symbol; 

10.  delete  inside  section; 

11.  delete  outside  section; 

12.  move  section;  and 

13.  modify  root,  prefix,  or  suffix  segment 
of  feature. 

m.  Separation/Layer  contro1  module: 

1.  separation  and  layer  select  for  digitizing. 

n.  Display/List  control  module: 

1.  circle/arc  roundness  select; 

2.  text  display  on/off  select; 

3.  grid  display  on/off  select; 

4.  layer/separation  (display/list)  select; 

5.  window  area  select  (1:1  or  auto-scaled); 

6.  trigger  hard  copy  of  screen  content;  and 

7.  cased  text  on/off  select. 

o.  Job  close  control  module: 

1.  close  files  and  log-off  on  fatal  error 
or  operator  command  (confirmed) . 

p.  Symbol  displciy  module; 

1.  display  point,  left-path,  right-path, 
left-area,  right-area  symbols;  and 

2.  handle  nesting  of  user  symbols,  with  or 
without  variable  text. 
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q.  Digitizing  control  (two  overlay  modules): 

1.  select/establish  feature  type:  path,  area-left, 
area-right,  fixed  or  variable  text,  point  symbol, 
path  symbol  left  or  right,  area  symbol  left  or 
right;  and 

2.  select/effect  data  type:  trace,  rectangle,  circle, 
cw  arc,  ccw  arc,  line/point,  polynomial  smoothing 
of  degree  2,  3,  or  4. 

r.  File  control  (four  overlay  modules): 

1.  clear  work  file; 

2.  clear  scratch  file; 

3.  store  work  or  scratch  file  as  symbol,  and 
clear; 

4.  recall  symbol  to  work  file,  normal,  or  shifted 
position; 

5.  recall  symbol  to  scratch  file,  normal,  or 
shifted  position; 

6.  store  current  drawing  file  and  open/establish 
new; 

7.  establish  new  symbol  file; 

8.  display  work  or  scratch  file;  and 

9.  list  drawing,  scratch,  or  symbol  files. 

All  of  the  interactive  graphic  software  is  written  in  FORTRAN  5 
with  the  exception  of  two  routines  which  handle  communications  with 
the  digitizing  table,  Tektronix  display  terminal,  and  station  Dasher 
hardcopy  terminal. 

2. 3. 3.4.2  EBR  Drive  Tape  Creation  Software.  The  EBRDC  software 
package  consists  of  a  main  (executive)  routine  and  49  subroutines 
organized  functionally  into  20  overlay  modules.  Each  execution  of  the 
package  processes  all  drawings  in  a  single  product  directory.  Eight  (8) 
of  the  modules  are  considered  "level  1"  functions  and  perform  one-time- 
per-run  or  one-time-per-drawing  operations  such  as: 

a.  initialize  output  magnetic  tape,  and  input  tape 

if  operator  indicates  an  archival  tape  exists  from 

a  previous  run; 


b.  initialize  program  arrays/areas/variables, 
initialize  directories,  and  open  files 
applicable  to  entire  product  directory; 

c.  build  a  temporary  image  index  file  for 
product  directory; 

d.  examine  each  drawing  file  and  create  a 
temporary  index  to  features  within  the 
drawing? 

e.  copy  images  of  a  drawing  (color/separation) 
which  have  not  been  altered  since  a  previous 
run  against  the  directory; 

f.  cycle  through  each  drawing  calling  "level  2" 
modules  to  convert  data  within  the  drawing  to 
EBR  format;  and 

g.  wrap-up  a  run,  outputting  final  data  blocks, 
closing  files,  deleting  temporary  files,  etc. 

The  level  two  (2)  software  consists  of  12  overlay  modules, 
three  (3)  of  which  process  line-path,  area,  and  textual  data  to  EBR 
form.  A  fourth  level  two  (2)  module  is  basically  a  dispatcher  routine 
to  load  and  call  one  (1)  of  the  nine  (9)  remaining  modules,  each  of 
which  processes  one  (1)  to  three  (3)  of  the  eleven  (11)  classes  of 
symbols  currently  being  used  on  FLIP  products. 

The  entire  EBRDC  package  is  written  in  FORTRAN  V  and  requires 
slightly  less  than  30K  words  of  memory  and  at  least  one  (1)  tape  trans 
port  for  execution. 

2. 3. 3.4.3  Chart/Publishing  Data  Merge  Software.  This  package  is 
actually  two  sequential  processes.  The  first,  known  as  EBRLOAD,  trans 
fers  the  contents  of  an  archival  EBR  tape  to  the  S/230  disk  drive  in 
a  product  directory  specified  by  the  operator.  The  names  of  the  disk 
files  created  correspond  to  the  sequence  in  which  the  files  are  found 
on  the  input  tape.  Other  than  system  library  routines,  only  one  small 
subroutine  is  used.  The  input  tape  is  dismounted  and  replaced  by  the 
tape  from  the  Publishing  Subsystem,  and  the  second-phase  process  is 
executed  to  perform  the  merge  and  write  a  complete  output  tape  with 
both  text  and  graphics. 

The  second  phase,  EBRMERGE,  consists  of  a  main  routine  and  six 
subroutines.  Together  this  software: 

a.  copies  textual  data  records  from  input  to  output  tape 
until  a  "graphic  call"  record  is  found  in  the  input 
tape ; 
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b.  opens  the  appropriate  disk  graphic  file  and 
determines  from  the  "call"  record  what  scale, 
rotation,  and  origin  shift  is  to  be  applied  to 
the  graphic.  (Scale  and  rotation  are  constant 
for  a  product  type) ; 

c.  if  the  requested  graphic  does  not  exist  for  any 
reason,  one  subroutine  is  used  to  substitute  a 
"null"  empty  box  at  the  specified  location;  and 

d.  two  subroutines  create  or  alter  EBR  command  data 
words  as  they  buffer  the  graphic  data  to  the 
output  tape. 

All  of  the  software  for  the  merging  process  is  in  FORTRAN  V. 

Figure  2-17  depicts  a  typical  data  flow  for  the  preparation  of  EBR 
tapes  as  described  above. 

2.3.4  AAIPS  Cartographic  Electron  Beam  Recorder 

The  AAIPS  Cartographic  EBR  system  fabricated  by  Image  Graphics,  Inc. 
under  subcontract  to  Synectics  Corporation  is  the  principle  cartographic 
output  device  of  the  Charting,  Publishing  and  Air  Facilities  subsystems. 

The  EBR  was  selected  as  the  AAIPS  output  device  because  it  is  capable 
of  high  speed,  high  quality,  and  versatile  plotting/recording.  Digital 
data  is  converted  by  the  EBR  into  images  on  electron  sensitive  film.  The 
EBR  provides  a  method  for  creating  the  final  separation  negatives  in  con¬ 
junction  with  existing  production  equipment.  The  EBR  possesses  the  accuracy, 
resolution,  and  flexibility  to  produce  graphics  art  quality  recording  out¬ 
put  consisting  of  line,  point,  area  symbology,  and  multiple  fonts  required 
by  the  Flight  Information  Products. 

The  EBR  is  a  complete  stand-alone  system  supported  by  a  DEC  PDP-11/341 
central  processor  with  64K  16-bit  word  core  memory,  automatic  power  fail 
detection/restart  and  direct  memory  access  interface.  Peripherals  include 
a  9- track  TE16  800/1600  bpi,  45  ips  magnetic  tape  transport/controller,  an 
RK11  dual  disk  drive  supporting  two  2.5  Mbytes  RKOJJ  disks,  and  an  LA36-CA 
decwriter  console  terminal. 

The  data  translator  circuits  of  the  EBR  are  contained  in  the  Symbol/ 
Vector  Generator  (SVG)  which  converts  digital  data  from  the  computer  into 
analog  signals  which  drive  the  EBR.  The  SVG  performs  character  and  symbol 
generation,  incremental  and  stroke  vector  recording,  variable  line  width 
control,  variable  character  size  and  orientation  variable  intensity 
control  for  gray  shade,  and  random  X-Y  positioning. 

A  Tektronix  619  storage  display  is  provided  to  allow  direct  running 
of  the  data  being  plotted  by  the  EBR. 
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TABLE  I 


TYPICAL  CARTOGRAPHIC  EBR  SYSTEM  PERFORMANCE  CHARACTERISTICS 


Film  Type 


Kodak  SO-219  unperforated 


Film  Size 


5-1/2"  wide 


Film  Capacity 
Film  Transport 
Registration  Holes 
Film  Pull  Down 


100  Feet  wound  on  3"  diameter 
cores,  emulsion  side  out 

Single/frame  pull  down  with 
registration  punches 

Two  1/4"  holes,  9  inches 
bounding  each  frame 

5  secs 


Minimum  Line  Width 


6  Urn 


Variable  Line  Widths 
(EBR  Image  Scale) 

Character  Sizes 
(EBR  image  scale) 

Character  Rotation 

Beam  Position 

Congruity  of  sequential 
images 

Geometric  Fidelity 


Maximum  optical  density 

Line  density  range 

(gray  shades,  discernible 

steps) 

Background  density 
Video  Bandwidth 


6  to  261  Um  with  8  bit  (256  levels) 
control,  in  1  hm  increments 

8-250  mils 
1°  Increments 

19,859  x  32,768  address  matrix 
over  a  5"  x  8-1/4"  format  area 

j^.003%  of  full  size  of  image 

+  . 01%  (with  software  correction) 

+_.  05%  (without  software  correction) 

2.35+ 

64 


0.1  density  unit 
DC  -  10  MHz 


Writing  Speeds 

Random  Points*  40K 

Adjacent  Points  (VIP)  120K 

Stroke  Vectors  10K 

Character  Generation  Speeds  IK 
(Characters  per  second  at  EBR  scale) 

8-2 50  mils  (Graphic  Arts)  characters/sec  (AVG)*** 


points/sec 

points/sec** 

points/sec 
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SECTION  3.  TRAINING 


3.1  REQUIREMENTS 


Training  for  ADP  systems  analysts,  programmers,  and  operators  was 
provided  as  part  of  the  overall  contract  obligation.  Training  was  provided 
at  DMAAC/AD  and  included  all  aspects  of  the  full  system  operation.  Type 
and  scope  of  training  to  be  provided  as  required  by  the  contract  was  as 
follows: 


a.  Training  for  systems  analysts  covering  computer 
operation,  operating  systems,  compilers,  assemblers, 
loaders/linkers,  libraries  and  other  support  soft¬ 
ware  ; 

b.  Training  for  programmers  would  include  familiarization 
with  the  system  operation  and  emphasize  the  applications 
software  provided;  and 

c.  Training  for  operators  would  include  both  formal 
classroom  instruction  as  well  as  hands  on  system 
demonstrations . 


3.2  TRAINING  PROGRAM 


Prior  to  conduct  of  the  training,  complete  training  course  outlines 
were  prepared  by  Synectics  and  reviewed  and  approved  by  appropriate 
Government  personnel.  The  course  outline  provided  specific  details  for 
the  agenda,  required  materials,  personnel  attending,  instructor  staff,  and 
topics  to  be  covered. 

Training  was  conducted  over  a  continuous  seven  week  period,  4  hours 
per  day  to  minimize  the  interference  with  usual  AD  production  schedules. 
Training  was  provided  on  a  subsystem  basis.  In  most  instances  DMAAC/ ADA 
programmers  and  analysts  attended  both  the  training  for  systems  analysts 
and  programmers  for  all  three  subsystems.  Extensive  training  aids  in  the 
form  of  briefing  handouts  and  computer  listings  were  provided.  Training 
required  intensive  participation  by  the  trainees .  Each  formal  instruction 
session  was  followed  by  classroom  quizzes,  which  provided  necessary  feed¬ 
back  to  instructor  personnel.  Remedial  review  of  difficult  subject 
matter  was  performed  immediately  before  moving  to  the  next  session. 

Systems  analyst  training  required  the  participation  of  trainees  in  a 
design  workshop.  Subsystem-related  problems  were  presented  and  trainees 
were  required  to  employ  modern  structured  design  techniques  to  outline 
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design  subsections.  Programming  assignments  were  similarly  made  to 
stimulate  creative  utilization  of  the  plentiful  software  development 
tools  provided  by  each  subsystem. 

The  training  program  attempted  to  bring  to  light  the  potential 
capabilities  inherent  within  the  AAIPS.  Strict  separation  of  major 
personnel  functions  and  rules  was  not  emphasized  because  fine  training 
of  personnel  functions  will  undoubtedly  take  place  in  time  as  management 
perceives  the  need  to  establish  them. 


SECTION  4.  TEST  AND  EVALUATION 


4.1  CONCEPT 


The  AAIPS  system  acceptance  and  evaluation  tests  were  performed  to 
demonstrate  the  AAIPS  capability  to  meet  or  exceed  all  specific  SOW 
requirements . 

A  comprehensive  system  test  and  evaluation  plan  for  Phase  II  was 
prepared  to  fulfill  the  following  objectives: 

a.  provide  concise  evidence  of  the  system's  capability 
to  accomplish  the  SOW  requirements; 

b.  serve  as  a  guide  for  management  by  objectives  to 
ensure  a  thorough  step-by-step  validation  of  the 
system's  functional/operational  capabilities; 

c.  coordinate  for  all  test  personnel  a  schedule  of 
events,  specification  of  equipment  and  organizational 
support,  test  methodology,  and  definition  of  specific 
test  procedures ■  and 

d.  to  provide  a  written  record  of  requirements  and 
evidence  of  their  satisfaction. 

The  test  procedures  can  be  categorized  in  the  following  way: 

a.  Demonstration  tests  -  which  require  furnishing 
evidence  of  satisfaction  of  a  system  attribute 
by  either  direct  hands-on  operation,  provision 
of  vendor  literature,  or  physical  inspection; 

b.  Functional  tests  -  which  requires  independent 
testing  with  a  confirmed  input  and  output. 

Interrelated  functions  may  be  tested  when 
individual  functions  cannot  be  tested  indepen¬ 
dently.  The  input/output  may  be  verified  by 
softcopy  display,  plot,  hardcopy  print  out, 

EBR  film  positive,  etc,-  and 

c.  Volume  Throughput  tests  -  which  involves  full 
subsystem  testing  in  a  pseudo-production  environ¬ 
ment  where  the  success  criteria  is  based  on 
processing  a  prescribed  volume  of  data  in  a 
particular  span  of  time. 
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In  order  to  assure  complete  traceability  of  all  test  events  and  mile¬ 
stones  to  the  contract  SOW,  a  SOW  Cross  Reference  Matrix  was  provided 
within  the  test  plan.  As  each  test  item  was  accomplished  the  particular 
SOW  requirement  tied  to  that  particular  test  was  signed  off  by  the 
appropriate  Government  witness. 

The  primary  purpose  of  the  Test  and  Evaluation  was  to  determine  the 
capability  of  the  system  to  support  full  production.  Functional  and 
demonstration  testing  was  to  be  conducted  for  each  subsystem  during  1  October 
1979  through  the  T&E  period  until  all  tests  were  successful.  Full  produc¬ 
tion  volume  T&E  was  conducted  from  1  November  1979  through  28  December  1979. 

The  execution  and  evaluation  of  all  functions  during  the  T&E  period 
was  performed  by  DMAAC  personnel.  The  DMAAC  personnel  was  responsible  for 
recording  all  the  necessary  data  to  permit  subsequent  evaluation  of  the 
system. 

All  demonstrational  and  functional  tests  as  prescribed  by  the  Test 
Plans  and  Procedures  Volume  I,  II,  III, and  IV  were  performed  successfully 
and  witnessed  by  Government  test  director  personnel. 


4.2  AIR  FACILITIES  SUBSYSTEM 


The  full  AAFIF  file  was  transported  from  the  U1108  and  loaded 
onto  the  Air  Facilities  Subsystem  disk  mass  storage.  The  full  production 
testing  required  that  real-world  transactions  would  be  used  to  update 
the  AAFIF  via  the  on-line  data  terminals.  One  day  of  real-world  trans¬ 
actions  would  be  performed  for  each  working  day  of  the  T&E.  The  data  base 
maintenance  would  be  performed  by  the  Aeronautical  information  specialists 
(AIS)  in  DMAAC/ ADA  who  had  previously  been  given  a  rudimentary  training 
orientation.  During  the  seven  weeks  of  T&E,  DMAAC/ADA  personnel  produced 
daily  listings  of  the  systems  utilization  log  to  verify  AIS  performance 
with  respect  to  the  volume  input.  Each  T&E  data  base  update  transaction 
was  captured  by  the  interactive  software  and  maintained  in  a  log  file. 
Hardcopy  output  of  old  and  new  contents  of  each  updated  element  was 
obtained  by  the  daily  printouts.  This  output  was  used  to  verify  the 
acceptability  of  the  subsystem  to  support  the  volume  input. 

The  interactive  data  base  maintenance  capability  achieved  an  average 
revision  time  of  less  than  2  1/2  minutes  per  element  update.  As  such  the 
16  terminal  configuration  provides  more  than  ample  capacity  to  support 
full  production  AAFIF  maintenance. 

The  data  base  maintenance  function  is  supported  by  the  capability 
of  the  subsystem  to  provide  AIS  positive  feedback  reports.  These  are 
hardcopy  reports  of  full  or  partial  airfields  that  have  been  changed  by 
the  AIS  and  are  automatically  generated  upon  request  by  the  AIS.  The 


reports  are  generated  following  the  prime  shift  when  all  data  base 
maintenance  activity  is  completed  for  the  day.  A  spool  file  is  gen¬ 
erated  and  may  be  printed  the  following  morning  and  distributed  to  AIS 
personnel.  The  throughput  for  this  function  during  T&E  probably  represented 
a  worst-case  since  it  is  anticipated  that  the  AIS  will  gradually  acquire 
greater  confidence  in  the  softcopy  display  for  review  and  not  rely  as 
heavily  on  the  hardcopy  reports.  Nevertheless,  the  spooling  process 
averaged  less  than  2  hours  and  the  printing  required  about  1.2  hours  each 
day. 


The  testing  involved  all  normal  production  activities  that  would 
necessarily  be  encountered  in  full  production.  This  included  daily 
maintenance  of  the  AAFIF  Card  Image  File  and  AAFIF  Mini  File.  These 
auxiliary  files  are  derived  from  AAFIF  information  and  are  maintained  by 
special  data  base  applications  programs .  These  files  were  provided  to 
ensure  greater  throughput  of  the  AA  ^F  application  programs. 

The  Card  Image  File  is  equivalent  in  format  to  the  current  U1108  AAFIF 
file  and  is  used  to  produce  history  tapes  having  the  same  format  as  those 
produced  by  the  U1108  HISTDUP  program.  The  card  image  file  and  its  index 
resides  on  4  disk  packs  and  occupies  a  space  equivalent  to  the  capacity 
of  3  full  disk  packs. 

The  card  image  file  is  built  on  a  one-time-only  basis  by  a  special 
program  which  converts  the  entire  AAFIF  information  to  card  image  format 
on  disk.  During  the  T&E  the  card  image  file  was  generated  in  251.5  hours 
of  elapsed  wall  clock  time.  Daily  maintenance  of  the  card  image  file 
which  utilizes  the  transaction  log  as  input  averaged  1.3  hours  per  day. 

The  other  major  auxiliary  file  is  the  AAFIF  Mini  file  which  consists 
of  subsets  of  significant  data  base  elements  extracted  from  each  airfield 
record  and  organized  by  airfield  installation  sequence.  The  mini  file 
occupies  less  than  5  percent  of  a  single  disk’s  capacity.  The  daily 
maintenance  of  the  mini  file  which  is  performed  by  special  applications 
software  averaged  less  than  5  minutes . 

The  daily  maintenance  of  the  auxiliary  files  must  precede  all  other 
applications  programs  job  streams  that  require  the  card  image  file  or 
mini  file  inputs. 

The  applications  program  throughput  testing  involved  four  typical 
AAFIF  output  processing  programs. 

The  HTAPE  program  which  outputs  the  card  image  file  information  to 
tape  in  the  HISTDUP  format  constituted  a  significant  part  of  the  volume 
testing.  The  success  criteria  demanded  that  a  complete  card  image  file 
be  recorded  on  tape  within  a  fifty-four  hour  period  (i.e.  ,  the  time  avail¬ 
able  for  processing  over  a  week-end) .  The  actual  test  results  realized 
output  of  the  complete  card  image  file  on  23  reels  of  tape  in  less  than 
42  hours  of  elapsed  wall  clock  time. 
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The  AFFUPDT  program  produces  the  DIA  transaction  tape  file.  Fixed 
element  transactions  and  variable  text  information  from  the  transaction 
log  combined  with  primary  AAFIF  file  information  was  used  to  produce  the 
DIA  tape.  This  weekly  production  program  averaged  less  than  1/3  hour 
of  wall  clock  time  per  run  during  T&E.  The  success  criteria  for  the  AFFUPDT 
throughput  was  established  at  4  hours  per  run. 

The  AFFINDEX  program  which  produces  a  hardcopy  report  of  relevant 
AAFIF  index  information  averaged  less  than  3  hours  per  run  during  the 
T&E  period.  Success  criteria  for  this  program  was  established  prior  to 
the  test  at  8  hours  per  run. 

The  ASSOTW  program  which  produces.  'BR  tapes  for  subsequent  EBR 
recording  of  film  images  of  the  ASSOTW  report  averaged  less  than  3/4 
hour  per  run  during  the  T&E.  Success  criteria  of  30  hours  per  run 
had  been  established  prior  to  the  testing. 

The  T&E  testing  proved  conclusively  that  the  Air  Facilities  Subsystem 
as  developed  during  Phase  II  provides  sufficient  storage  capacity  and 
processing  performance  to  support  full  production. 


4.3  PUBLISHING  SUBSYSTEM 


Prior  to  the  T&E  period  a  representative  FLIP  textual  test  data 
base  was  acquired.  The  products  included:  PAA  enroute  supplement;  Area 
planning/3;  Area  Planning/3A;  US  VFR  supplement;  and  document  MAN's  and  PCN's. 
A  pseudo  production  schedule  spanning  three  hypothetical  information 
cutoff  dates  was  established.  Revisions  were  performed  on  the  basis  of 
three  "real-world"  days  of  transactions  for  each  day  of  T&E.  The  product 
maintenance  was  performed  by  DMAAC  text  composers  who  had  become  quite 
familiar  with  the  system  but  technically  had  not  received  any  formal 
training.  On  the  ICOD  data  all  applicable  products  were  repaginated  and 
recorded  on  the  EBR.  Products  that  required  merging  with  graphics  pro¬ 
duced  by  the  Charting  subsystem  were  similarly  prepared  for  EBR  recording. 

Film  processing  was  performed  in  the  DMAAC /GA  photo  laboratory  and  lithos 
were  produced  for  evaluation  purposes. 


4.4  CHARTING  SUBSYSTEM 


The  test  data  base  for  the  Charting  T&E  included  the  following 
products:  12  PAA  enroute  charts,  4  African  enroute  charts,  as  many  PAA 
IAP's  as  practicable  (digitization  of  new  IAP's  continued  throughout  the 
T&E  period  but  digitization  times  were  not  counted  as  part  of  the  T&E) , 
26  AFR  IAP's  and  30  pages  of  the  US  VFR  Supplement.  The  graphic  FLIP 
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production  schedule  was  divided  into  three  simulated  maintenance  cycles  with 
the  same  information  cutoff  dates  as  used  for  the  Publishing  Subsystem. 

The  revisions  were  performed  by  trained  but  relatively  inexperienced  aero¬ 
nautical  chart  maintenance  specialists.  The  data  abstracts  (DA's)  which 
specify  the  particular  graphic  changes  were  separated  by  individual  product 
and  chronologically  sorted.  Each  day  of  T&E  the  DA's  for  that  particular 
date  were  distributed  uniformily  to  schedule  a  balanced  workload  on  each 
workstation.  One  day  of  real-world  changes  were  performed  for  each  day 
of  T&E.  DMAAC  test  personnel  were  responsible  for  capturing  the  statistical 
revision  performance  data  and  maintaining  the  T&E  log. 

Chart  revisions  were  performed  by  superimposing  over  the  printed  litho 
containing  the  changes  a  previous  cycle  film  positive  that  does  not  have 
the  changes.  With  the  hardcopy  DA  of  the  analysts ' changes  the  operators 
were  able  to  identify  where  each  change  occurred.  For  minor  revisions 
the  changes  were  simply  marked  on  the  previous  cycle  watercoat  proof. 
Terminal  procedure  changes  were  generally  conveyed  directly  from  the  DA's 
unless  the  change  was  major.  In  these  cases  the  changes  were  drawn  on 
an  overlay  and  furnished  to  the  compiler. 


4.5  ELECTRON  BEAM  RECORDER 


The  test  and  evaluation  and  acceptance  of  the  EBR  by  Synectics  from 
Image  Graphics,  Inc.  (IGI)  took  place  during  Phase  I  of  the  AAIPS  effort. 
Preliminary  acceptance  was  performed  at  the  IGI  manufacturing  operation. 

Test  and  Evaluation  was  conducted  at  DMAAC/AD  where  the  factory  acceptance 
test  was  repeated  and  an  80-hour  production  environment  test  was  performed. 

During  Phase  II  simulated  full  production  for  the  AAIPS  FLIP/AAFIF  pro¬ 
duction  included  utilization  of  the  EBR  for  recording  the  AAIPS  products. 

The  first  objective  of  the  EBR  T&e  was  to  assure  quality  consistency  pro¬ 
ducts  are  produced  to  meet  a  standard.  The  second  objective  was  to  deter¬ 
mine  the  EBR's  capability  to  accomplish  the  FLIP  recording  workload  in 
a  reasonable  period  of  time. 

To  support  the  quality  objective,  Synectics  strived  throughout  the 
life  of  the  project  to  develop  and  validate  comprehensive  EBR  film  pro¬ 
duction  training  procedures  and  safeguards  to  assume  product  quality. 

Three  types  of  quality  standards  were  identified.  Type  I  tests  relate  to 
the  film  processing  method  and  associated  standards  of  chemistry,  densitometry, 
handling,  etc.  Data  Content  validity  tests  for  proofing  the  graphic/text 
information  by  softcopy  display  or  hardcopy  review  are  of  the  Type  II 
variety.  Type  III  tests  are  allied  to  hybrid  indirect  medium  measurement 
by  an  instrument  known  as  the  Neutral  Test  Package  (NTP) .  The  NTP  is  a 
previously  validated  mechanism  that  is  employed  as  a  total  production  train¬ 
ing  quality  measuring  device.  The  NTP  embodies  all  quality  related  con¬ 
ditions  including  new  film  stations,  film  handling  and  processing  procedures, 
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chemical,  software,  and  EBR  status  as  well  as  human  intervention  arising 
from  all  activities  performed  in  the  past  production  train.  Further, 
Synectics  created  a  "Phased  Joint  EBR/EBR  Film  Quality  Control  Procedure" 
(reference  Figure  4-1)  employing  all  three  types  of  quality  safeguards 
which  were  to  be  faithfully  adhered  to  during  the  Phase  II  T&E  period. 

For  a  number  of  reasons  the  EBR  film  quality  test  objective  could 
not  be  authentically  established  during  the  Phase  II  T&E.  These  reasons 
included: 


a.  lack  of  established  film  product  standards; 

b.  unscheduled  film  processing  routines; 

c.  oversized  film  processing  units; 

d.  inappropriate  film  developing  chemistry; 

e.  improper  film  orientation  during  film  processing;  and 

f.  failure  to  exercise  the  NTP  as  agreed  upon  in  the 
Test  Plans  and  Procedures. 

Also  the  medium  prescribed  for  final  quality  evaluation  as  called  for 
by  the  test  scenario  was  the  processed  fixed  original  EBR  film  product. 
Unfortunately  access  to  the  original  film  was  precluded  by  other  express 
needs  of  the  Government.  The  only  recourse  was  in  the  form  of  later 
generation  paper  replicas  which  may  mash  or  obscure  film  quality  as  well 
as  distort  minor  film  defects.  All  quality  assessment  during  the  T&E 
tests  was  subjectively  derived  from  the  paper  surrogate  products.  The 
impact  on  film  product  quality  resulting  from  the  combined  set  of  circum¬ 
stances  described  above  could  not  be  directly  ascertained. 

EBR  recording  performance  data  revealed  acceptable  throughput  results. 
In  spite  of  the  high  speed  writing  speeds  inherent  in  the  EBR,  overall 
throughput  is  heavily  affected  by  system  constraints  such  as  the  control 
processor,  memory  size,  disk  transfer  rates,  software  and  capacity  of 
the  vacuum  system.  The  latter  constraint  is  imposed  by  the  duty  cycle 
of  the  vacuum  pumps  which  limits  throughput  to  a  miximum  of  60  frames  per 
hour.  Nevertheless,  EBR  recording  times  (non-archival)  for  the  FLIP 
products  were  quite  satisfactory  as  follows: 

a.  21  minutes/enroute  chart; 

b.  4  minutes/terminal  procedure; 


2.5  minutes/supplement  page; 
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d.  3  minutes/planning  document  pages;  and 

e.  4  minutes/VFR  supplement  page. 

Problems  encountered  during  the  T&E  directly  attributable  to  the 
EBR  anomalies  included  rare  occurrences  of  text  lines  randomly  misplaced 
within  a  page  of  text.  Also  evidences  of  occurrences  of  residual  mag¬ 
netism  which  can  distort  beam  positioning  were  occasionally  spotted.  This 
problem  relates  to  the  current  state  of  the  art  and  is  not  currently 
remedial . 


SECTION  5. _ CONCLUSIONS  AND  RECOMMENDATIONS 


5.1  GENERAL 


The  Automated  Air  Information  Production  System  (AAIPS)  as 
designed,  implemented  and  tested  at  the  Defense  Mapping  Agency 
Aerospace  Center  (DMAAC)  Aeronautical  Information  Department 
(AD)  meets  or  exceeds  the  performance  requirements  for  the 
automated  production  of  high  quality  and  timely  Flight  Infor¬ 
mation  Products.  This  also  includes  the  redesign  of  Automated 
Air  Facility  Implementation  File  ( AAFIF)  and  providing  the 
capability  for  on-line  interactive  data  base  maintenance  and 
AAFIF  product  generation.  The  AAIPS  implementation  included 
all  the  hardware,  software,  procedures,  and  test  data  bases 
defined  in  the  Phase  I  AAIPS  Design  Plan  and  later  augmented 
during  Phase  II  by  a  design  revalidation  based  on  the  pilot 
system  test  and  evaluation  results  and  a  complete  analysis  of 
the  FLIP  and  AAFIF  full  production  requirements. 

The  conclusions  and  recommendations  for  the  future  AAIPS 
transition  into  full  production  are  described  in  this  section. 

Our  conclusions  are  based  on  the  results  of  acceptance  testing 
and  our  intimate  experience  with  the  system  throughout  the  three 
years  of  developmental  activity. 

Certainly  our  perception  of  the  needs  of  the  system  today 
is  clearer  than  when  the  original  AAIPS  SOW  specification  was 
developed  over  three  years  ago.  The  recommendations  advocated 
in  this  section  address  particular  improvements  to  the  AAIPS 
operational  procedures  to  ensure  success  during  transition  to 
the  production  environment.  Longer  range  recommendations  that 
include  certain  hardware  reconfigurations  and  upgrades  are 
stated  from  the  multiple  vantage  points  of  advances  in  tech¬ 
nology  and  awareness  of  shortfalls  in  the  provision  for  adequate 
backup  capability  in  the  original  contractual  system  architecture. 


Finally,  it  is  our  opinion  that  DMAAC/AD  needs  to  be 
postured  to  anticipate  future  trends  in  technology  and  require¬ 
ments  and  to  be  prepared  to  respond  to  their  emergence  by 
assessing  system  impacts  and  planning  compatible  solutions. 


<■ 
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5.2  CONCLUSIONS 


Based  on  the  evaluation  of  the  test  and  acceptance  data 
during  the  Phase  II  development  period  the  resulting  conclu¬ 
sions  can  be  made  relative  to  the  AAIPS  performance . 


5.2.1  Charting  Subsystem 


The  capability  to  satisfy  the  full  production  workload 
including  the  product  maintenance  and  EBR  output  preparation 
was  confirmed. 

The  procedures  for  interactive  revision  of  the  product 
data  bases  proved  to  be  extremely  efficient.  Throughout  the 
T&E  period  the  collective  proficiency  of  the  operators  im¬ 
proved  resulting  in  steadily  declining  average  revision  times . 

It  was  discovered  also  that  revision  throughput  times  were 
invariant  of  product  type.  Although  the  mix  of  T&E  revisions 
had  greater  percentage  of  complex  features  the  average  revision 
time  was  about  5  minutes  per  feature.  Elapsed  wall  clock  times 
including  all  aspects  of  system  -  related  functions,  display 
generation,  and  hardcopy  proofing  were  included  in  the  revision 
throughput  times.  It  was  noted  that  over  20%  of  the  interactive 
revision  time  is  used  for  graphic  display.  Indeed  during  Phase 
II  the  CRT  display  software  was  modified  to  permit  an  improve¬ 
ment  in  display  speed  of  from  20%  to  40%  over  the  original 
pilot  software  performances.  Also  during  Phase  II  the  message 
printout  throughput  for  the  interactive  audit  trail  was  im¬ 
proved.  The  original  printouts  were  prefaced  by  a  brief  but 
frustrating  delay.  The  messages  are  now  printed  immediately 
and  provide  a  satisfactory  prompting  for  the  operator  to 
continue  the  next  operation. 

Another  improvement  to  the  interactive  revision  capability 
was  implemented  during  PHASE  II  to  greatly  simplify  the  pro¬ 
cedure  for  making  straight  lines  either  "true"  horizontal  or 
vertical.  This  capability  was  especially  beneficial  to  the 
data  capture  process  for  the  enroute  charts. 
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Although  the  procedures  for  performing  interactive  revisions 
are  acknowledged  to  be  very  human  factor  oriented,  there  are 
some  items  worthy  of  improvement.  For  example,  area  symbols 
with  minor  subarea  "cut  outs"  must  be  deleted  and  redigitized  if 
a  subarea  boundary  is  to  be  changed.  Since  the  frequency  of  this 
type  of  change  is  very  low,  the  overall  revision  throughput  is 
not  adversely  effected.  However,  performing  this  type  of  edit 
is  cumbersome  and  frustrating  for  the  operator.  Similarly,  the 
procedure  for  text  revision  requires  the  original  text  feature 
to  be  deleted  and  the  new  text  to  be  re-entered.  Fortunately, 
text  entry  and  positioning  may  be  accomplished  on  the  Charting 
Subsystem  very  efficiently.  Nevertheless,  the  graphic  FLIP 
products  contain  a  large  amount  of  text  (especially  the  enroute 
charts)  and  text  features  are  associated  with  a  high  incidence 
of  change.  This  indicates  that  a  better  procedure  for  text 
editing  would  contribute  to  even  greater  revision  throughput. 

Evaluation  of  the  graphic  test  data  produced  in  conjunction 
with  the  Phase  II  T&E  revealed  the  need  for  the  establishment 
of  production  proofing  procedures.  Numerous  occasions  of  spelling 
errors,  wrong  font  selections,  improper  data  positioning,  incorrect 
line  weights  and  symbol  selection,  text  justification  and  size 
lapses,  and  differential  font  leading  were  exhibited  throughout 
the  graphic  data  base.  The  presence  of  such  data  errors  was  not 
construed  as  a  deficiency  of  the  subsystem.  Rather  neglect  on 
the  part  of  the  test  personnel  to  exercise  the  error  suppression 
mechanisms  available  in  the  form  of  hardcopies  derived  from  FLIP 
specifications  and  operating  experience  contributed  to  the  high 
incidence  of  data  errors.  The  failure  to  correct  the  data  de¬ 
ficiencies  was  evidence  that  production  quality  control  procedures 
were  not  observed 

The  error-free  quality  and  throughput  performance  of  the  EBR 
preparation  software  (EBRDC)  was  proven  acceptable  to  support  full 
production.  Successful  and  timely  conversion  of  the  product 
drawing  files  to  EBR  output  tapes  requires  that  EBR  preparation 
activities  be  carefully  scheduled. 

While  data  base  maintenance  of  all  product  directories  is  a 
perpetual  activity  throughout  the  product  cycle,  the  bulk  of  the  EBR 
film  recording  is  accomplished  3  weeks  before  the  actual  ICOD  date. 
Interim-archival  EBR  preparation  during  the  second  and  third  weeks 
reduces  the  processing  burden  at  the  ICOD.  The  final-archival  EBR 


preparation  updates  all  products  to  be  published  on  the  ICOD  and 
only  images  that  have  changed  since  the  first  week  of  the  current 
AIRAC  need  to  be  EBR  recorded.  The  three  modes  of  EBR  preparation 
are  explained  as  follows: 

a.  Non-archival  -  reprocesses  all  drawing  file  data 
and  generates  all  new  image  data  on  the  EBR  output 
tape ; 

b.  Interim-archival  -  reprocesses  only  color/screen 
separations  that  had  changed  since  the  last  run 
and  merges  these  with  images  copies  from  the 
last  archival  EBR  tape;  and 

c.  Final-archival  -  similar  to  the  interim-archival 
mode  but  also  flags  all  images  that  have  not 
changed  since  the  last  non-archival  run  so  they 
will  not  be  recorded  by  the  EBR. 

The  EBR  preparation  software  and  the  graphic  product  directories 
are  transportable  between  the  Charting  and  Publishing  Subsystems.  Typical 
non-archival  run  times  are  45  minutes  and  5  minutes  for  enroute  charts  and 
the  terminal  procedures,  respectively.  Interim-archival  times  of  10 
minutes  per  chart  and  4  minutes  for  the  procedures  were  experienced  during 
the  T&E  period.  The  final-archival  times  were  slightly  better  and  averaged 
8  minutes/chart  and  4  minutes/procedure. 

The  net  effect  of  the  EBR  preparation  strategy  is  to  balance  the 
workload  over  the  28-day  cycle  and  to  minimize  the  backlog  at  the  ICOD 
for  both  the  Charting  Subsystem  and  the  EBR.  The  EBR  preparation  proces¬ 
sing  workload  was  projected  based  on  the  T&E  average  throughput  time  as 
applied  to  the  worst-case  FLIP  production  schedule.  The  evaluation  re¬ 
sults  predict  that  the  Charting  Subsystem  can  effectively  support  the 
FLIP  full  production  on  a  three-shift  per  day/five  day  per  week  basis. 


5.2.2  Publishing  Subsystem 

The  Phase  II  test  and  evaluation  results  confirmed  the  capability 
of  the  Publishing  Subsystem  to  completely  support  full  production. 
Certain  software  modifications  to  the  pilot  software  were  provided 
during  Phase  II  to  improve  the  human  interactive  responsitivity .  These 
included  the  following: 

a.  Additional  INFORMER  CRT  display  information  to 
indicate  the  current  Datagraphi x  CRT  cursor 
position  (in  half  pica)  and  the  total  number  of 
characters  on  the  current  page ; 
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b.  An  improved  scrolling  capability  which  may 
be  invoked  in  conjunction  with  the  repeat 
(KEPT)  key  and  other  Datagraphix  keyboard 
keys.  This  permits  a  continuous  forward 
or  backward  scroll  by  either  a  line  or 
word  at  a  time.  Scrolling  is  performed 
only  on  the  current  page  ; 

c.  Airfield  Retrieval  by  name  (minimum  of 
first  4  characters)  for  publications 
indexed  accordingly  ; 

d.  Variable  leading  (positive  or  negative) 
to  override  the  default  leading 

e.  Proof  listing  improvement  to  enable  lower¬ 
case  line  printer  output  and  to  optionally 
bypass  embedded  non-printing  text  composition 
commands ; 

f.  Footnote  characters  and  the  words  they  are 
associated  with  are  treated  as  single  non- 
hyphenated  units; 

g.  Disable  certain  keyboard  keys  that  could  inad¬ 
vertantly  cause  a  termination  to  the  Publishing 
interactive  software;  and 

h.  A  pervasive  "HELP"  function  to  assist  new 
operators  may  be  invoked  at  any  query/response 
mode  in  the  interactive  display. 

The  improved  product  revision  capability  proved  to  be  very  efficient 
as  evidenced  by  the  average  revision  times  experienced  during  the  T&E 
period.  Typical  revision  times  were  6  minutes  per  planning  document 
change  and  3  minutes  per  supplement  revision.  Applying  these  results 
to  the  worst-case  full  production  FLIP  schedule  indicates  that  the  pub¬ 
lication  revisions  can  be  completely  supported  on  a  single-shift  operation 
bas is . 

One  of  the  major  goals  of  Phase  II  was  to  improve  the  throughput 
time  of  the  EBR  Preparation/Repagination  software.  The  improved  soft¬ 
ware  was  capable  of  throughput  performance  six  times  greater  than  the 
original  pilot  software.  During  T&E  the  dual  terminal  mode  of  operation 
(dual  concurrent  processing)  revealed  a  30%  overall  throughput  improve¬ 
ment  over  the  single  terminal  mode.  The  T&E  results  also  revealed  that 
the  archival  repagination  processing  mode  was  approximately  10%  slower 
than  the  non- archival  mode.  However,  the  archival  mode  conclusively 
proved  its  effectiveness  in  reducing  the  EBR  recording  workload  at  the 
ICOD  date. 


The  assessment  of  the  ability  of  the  Publishing  Subsystem  to  support 
full  production  throughput  was  based  on  the  worst-case  FLIP  full  production 
schedule.  The  most  effective  procedure  for  accomplishing  the  production 
workload  is  to  perform  a  pre-ICOD  non-archival  EBR  preparation  (repagina¬ 
tion  run  on  all  publications  scheduled  for  the  ICOD  after  all  but  the  last 
week  of  revisions  have  been  made) .  The  post-ICOD  archival  run  will  then 
minimize  the  EBR  recording  burden  since  only  pages  that  have  changed 
during  the  last  week  will  have  to  be  recorded  after  the  ICOD.  The  pro¬ 
jected  workload  for  the  Publishing  Subsystem  including  residual  EBR 
preparation  for  the  Charting  Subsystem  can  be  accomplished  on  a  two-shift 
operation  during  the  first  three  weeks  of  the  28-day  cycle  and  on  a  three- 
shift  basis  for  the  last  week. 

It  is  apparent  that  the  cooperative  utilization  of  the  three  processors 
of  the  Charting  and  Publishing  Subsystem  provides  more  than  adequate 
capacity  to  support  the  worst-case  FLIP  full  production  requirement. 


5.2,3  Air  Facilities  Subsystem 

The  capability  to  support  the  full  production  workload  which  includes 
maintenance  of  the  AAFIF  file  and  scheduled  and  non-scheduled  tape  and 
report  generation  of  products  derived  from  the  AAFIF  file  was  verified. 

The  hardware  configuration  to  support  the  remote  terminal  communica¬ 
tions  and  the  full  AAFIF  file  proved  to  be  fully  responsive  to  the  AD 
environment. 

The  AAFIF  data  base  redesign  proved  to  be  both  economical  in 
disk  storage  and  fast  in  terms  of  retrieval  time.  The  complete  AAFIF 
file  and  its  multi-level  indexes  resides  on  three  disk  packs. 

The  interactive  data  base  maintenance  capability  has  been  shown  to 
be  very  well  human-engineered  and  efficient.  The  air  information  analysts 
(AIS)  found  the  system  to  be  easy  to  use  and  averaged  2.5  minutes  per 
element  update  during  the  T&E.  This  represents  a  300%  reduction  in  time 
as  compared  to  our  original  design  plan  estimate.  The  response  times 
at  the  terminals  were  very  acceptable  to  the  users,  which  indicates  that 
a  successful  combination  of  system  hardware/software  and  data  terminal 
equipment  was  achieved.  The  subsystem  will  easily  accomodate  the  AAFIF 
maintenance  on  a  single  shift  basis. 

The  AAFIF  applications  programs  output  processing  performance  was 
successfully  demonstrated  during  the  test  and  evaluation.  These  programs 
will  be  scheduled  for  execution  during  the  second  and  third  shifts  in 
order  not  to  interfere  with  the  interactive  data  base  maintenance. 
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Prior  to  running  the  output  processing,  a  daily  card  image  and  mini  file 
maintenance  job  stream  must  be  performed.  These  auxiliary  files  must  be 
updated  prior  to  the  output  production. 

The  capacity  of  the  Air  Facilities  Subsystem  to  support  the  ASSOTW 
report  generation  and  the  other  scheduled  and  non- scheduled  tape  and 
hardcopy  reports  was  derived  from  extrapolation  of  the  T&E  results 
for  the  AFFUPDT,  AFFINDEX,  ASSOTW,  and  HTAPE  program  performance  relative 
to  the  full  production  volume. 

The  Phase  II  effort  was  a  major  challenge.  First  a  completely  new 
computer  system  was  acquired  and  installed.  Software  on  the  C-330  was 
predominantly  programmed  in  FORTRAN- IV  and  the  operating  system  RDOS,  a 
relatively  simple  foreground/background  monitor.  The  M-600  has  a 
sophisticated  multiprogramming  operating  system  (AOS)  which  presented 
a  "quantum-leap"  in  capability.  The  pilot  interactive  software  was 
transported  to  M-600  and  converted  to  FORTRAN-V,  a  faster  and  more 
efficient  language  than  FORTRAN-IV.  The  goal  was  to  maximize  the  legacy 
of  the  pilot  software  while  not  compromising  the  flexibility  and  per¬ 
formance  of  AOS.  Another  complication  was  the  inherent  differences  in 
the  file-oriented  data  base  software  (INFOS)  as  implemented  under  RDOS 
and  AOS. 

There  were  a  number  of  items  identified  during  the  pilot  T&E  that 
required  corrective  action.  First,  logic  checks  after  the  complete 
entry  of  a  new  airfield  or  an  update  to  an  old  airfield  were  performed 
inefficiently  by  the  pilot  interactive  software.  The  logic  check  would 
check  all  elements  in  the  airfield  whether  or  not  they  had  been  updated 
and  would  stop  on  the  first  occurrence  of  a  logic  failure.  The  new 
interactive  software  was  improved  to  perform  logic  checks  on  only 
elements  that  are  logically  related  to  the  updated  elements  and  all 
failures  are  flagged.  Also  the  diagnostics  indicate  the  name  of  the 
logic  table  which  detects  each  failure  and  the  AIS  is  able  to  more 
quickly  ascertain  this  error. 

The  second  improvement  involved  the  airfield  add  function.  The 
AIS  was  not  able  to  edit  previously  entered  elements  on  the  current 
airfield  being  added,  but  rather  was  forced  to  sequence  through  each 
category  until  the  whole  airfield  had  been  entered.  Only  after  the 
airfield  was  completely  defined  would  the  AIS  be  able  to  return  to 
correct  known  data  entry  errors.  Further,  the  AIS  could  not  log-off  with 
the  new  airfield  in  a  partial  state  of  completion  without  having  the 
airfield  purged  by  the  system.  The  Phase  II  software  was  improved  to 
permit  the  AIS  to  edit  and  verify  a  category/subcategory  after  performing 
the  initial  data  entry  and  prior  to  sequencing  to  the  next  category /sub¬ 
category.  The  AIS  can  log-off  and  return  at  a  later  time  to  continue 
building  a  partially  complete  new  airfield.  The  airfield  does  not  become 
a  part  of  the  data  base  until  a  full,  extensive  logic  check  is  performed 
to  verify  that  the  new  airfield  is  logically  valid  and  complete  (includes 
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all  prime  elements) .  The  logic  checks  for  an  updated  element  were  also 
made  efficient.  Typically  the  AIS  will  perform  a  number  of  element 
updates  to  an  airfield.  At  the  time  when  the  AIS  installs  the  airfield, 
logic  checks  are  performed  on  all  updated  elements.  The  logic  check 
involves  the  elements  that  were  updated. 

An  airfield  add  by  batch  card  input  capability  was  also  provided. 

This  allows  a  card  deck  of  airfield  record  data  to  be  keypunched  off¬ 
line  by  clerical  personnel.  This  contributes  to  more  effective  utiliza¬ 
tion  of  the  terminals  and  better  use  of  personnel  resources. 

The  card  deck  is  processed  by  a  two-pass  operation.  The  first  pass 
performs  a  format  check  to  null  elements  to  detect  syntax  errors.  A 
diagnostic  report  would  be  printed  and  returned  to  the  AIS  for  correction. 
Having  passed  the  format  checks,  the  second  pass  performs  a  full  exten¬ 
sive  logical  check  on  all  elements.  Again  a  diagnostic  report  is 
printed  for  the  AIS  for  review.  The  AIS  may  then  perform  all  required 
corrections  interactively  at  the  terminal  until  the  new  airfield  can  be 
installed. 

Another  interactive  software  improvement  was  to  distinguish  between 
three  types  of  airfields:  (1)  US;  (2)  Foreign  Freeworld;  and  (3)  Air¬ 
fields  having  runways  less  than  2000  feet  and/or  unused  runways.  The 
reason  for  the  distinction  is  that  depending  on  the  airfield  type, 
certain  elements  may  be  ignored  or  certain  elements  may  be  computed. 

It  was  felt  that  machine  editing/data  entry  should  be  streamlined 
for  the  AIS  so  the  user  would  not  be  forced  to  enter  irrelevant  elements 
(depending  on  the  type  of  airfield  being  updated) .  The  interactive 
software  now  displays  only  the  relevant  elements  depending  on  the  air¬ 
field  type.  The  AIS  need  be  concerned  only  with  element  information  that 
is  displayed.  However,  the  AIS  has  the  capability  to  override  the 
default  display  mode  and  display/modify  all  elements  in  the  airfield 
if  it  is  so  desired. 

Other  interactive  improvements  included  a  better  text  editing 
capability  which  permits  only  the  data  entry  of  valid  printing 
characters.  Each  softcopy  display  screen  is  appropriately  marked  with 
a  security  banner.  The  UTM  coordinates  of  the  airfield  were  com¬ 
puted  by  the  interactive  software  and  incorporated -during  Phase  II. 

The  interactive  dialog  was  improved  by  providing  clear  and  simple  in¬ 
structions.  The  display  copy  option  was  removed  from  the  interactive 
menus  and  replaced  by  a  positive  feedback  report  mechanism.  The  AIS 
can  select  either  a  full  airfield  or  a  partial  category/subcategory 
printout  as  desired.  The  print  is  spooled  and  printed  later  in  the  day 
and  returned  the  following  day  to  the  AIS.  The  printouts  are  sorted  by 
analyst  code  which  facilitates  distribution. 

A  much  improved  security  log-on  capability  was  provided.  A  time 
limit  on  each  CRT  after  log-on  is  invoked  for  idle  utilization.  After 
5  minutes  of  activity  the  master  console  operator  is  advised  of  the 


condition  and  takes  whatever  appropriate  action  is  required  including 
terminating  the  session  if  necessary.  The  password  system  was  revised  to 
permit  each  AIS  to  have  a  respective  password.  Further  the  AIS  is  permitted 
access  to  only  airfields  tagged  with  country  codes  and  WACs  that  are 
affiliated  with  this  unique  analyst  code.  In  this  manner,  the  integrity 
of  AAFIF  is  assured.  Three  successive  failures  by  am  AIS  to  access  an 
airfield  within  the  geographical  area  of  interest  carries  a  warning 
message  to  be  reported  on  the  master  console  for  the  system  operator  to 
take  appropriate  action.  Most  important  is  that  data  base  security  is 
provided  to  assure  that  the  airfield  information  will  be  maintained 
exclusively  by  the  AISs  for  only  the  areas  for  which  they  alone  are 
responsible. 

A  major  capability  to  perform  data  base  retrieval  by  interactive 
parameter  selection  was  provided  during  Phase  II.  The  special  retrieval 
permits  an  area  search  to  be  performed  on  the  AAFIF  file  in  which 
multiple  areas  can  be  selected  by  specifying  geographic  cover  coordinate 
limits  and/or  sets  of  WAC  cell  ranges.  Boolean  expressions  involving 
unlimited  combinations  of  data  base  elements  and  their  conditional  values 
(content)  and  logical  relationships  provide  the  extraction  criteria. 

The  retrieval  produces  a  "hit"  file  of  airfield  record  keys.  The 
resulting  "hit"  file  of  airfield  record  keys  may  be  used  by  any  applica¬ 
tions  program  to  retrieve  the  airfield  records  matching  the  search 
criteria.  The  Boolean  retrieval  is  used  in  conjunction  with  Special  Air 
Information  Request  (SAIR)  processing.  It  is  an  interactive  function 
and  requires  a  Boolean  logic  table  to  be  constructed  prior  to  invoking 
the  search. 

The  Phase  II  effort  required  the  AAFIF  file  structure  to  be  redesigned 
based  on  the  undesirable  throughput  performance  experienced  with  the  pilot 
subsystem.  The  resulting  INFOS  data  base  structure  is  flexible  in  terms 
of  permitting  data  element  growth  and  file  expansion.  The  Phase  II  AAFIF 
file  was  designed  for  efficient  disk  space  utilization  and  currently  the 
45,000  airfield  records  and  indexes  reside  in  their  entirety  on  three 
192M  byte  disk  packs.  The  design  also  optimized  airfield  record  retrieval 
time.  Special  INFOS  interface  software  was  written  to  permit  an  entire 
subcategory  of  data  elements  to  be  accessed  at  one  time  with  minimal 
disk  accessing  and  completely  transparent  to  the  applications  program 
using  the  interface  software.  A  FORTRAN  INFOS  interface  module  was 
developed  to  preserve  the  legacy  of  the  interactive  software  which 
logically  accesses  a  single  element  at  a  time.  Similarly  programming  new 
AAFIF  applications  programs  is  facilitated  by  the  availability  of  a  COBOL 
interface  package  which  permits  the  programmer  to  have  the  same  logical 
view  of  the  data  base  as  the  AIS  user.  The  applications  programs  need 
not  be  concerned  with  the  physical  storage  structure  of  the  data  base. 

The  interface  software  permits  an  entire  subcategory  of  data  elements  to 
be  accessed  at  one  time  transparently  to  the  applications  program.  The 
COBOL  interface  provides  a  mechanism  to  protect  the  applications  programs 
from  evolving  data  base  changes. 


Schema/Subschema  element  definitions  are  maintained  for  each  sub¬ 
category  in  a  common  COPYLIB  library  for  utilization  by  all  applications 
programmers . 

An  on-line  data  dictionary  provides  a  means  to  define  and  manage 
the  data  base  schema/subschema  structure.  The  data  dictionary  permits 
AIS  users  to  review  the  logical  content  of  the  data  brse.  The  data 
base  administration  is  facilitated  by  the  data  dictionary  in  respect 
to  being  able  to  manage  data  base  changes.  Evolutionary  change  is  broadcast 
to  the  AIS  users  as  an  integral  part  of  the  data  base  maintenance  opera¬ 
tional  procedure.  Special  software  to  automatically  reconfigure  the 
data  base  for  the  addition(  deletion  or  modification  of  element  defini¬ 
tions  is  provided.  Software  has  also  been  provided  to  automatically 
move  air  facilities  installations  to  new  countries,  reassign  analyst 
code  responsibilities  to  different  country  code  and  WACs ,  and  to  handle 
country  code  changes. 

SAIR/DAIR  processing  is  facilitated  by  the  availability  of  the 
Boolean/Geographic  Retrieval,  SORT  facility,  AAFIF  Mini  file,  and  the  RPG 
language  processor.  The  data  base  retrieval  "hit"  file  contains  airfield 
record  keys  which  can  also  be  utilized  to  access  information  from  the 
auxiliary  files  (i.e..  Card  Image  file  and  Mini  file).  Alternatively, 
the  Mini  file  can  be  searched  directly  by  means  of  a  simple  COBOL  program 
or  by  appropriate  setup  of  the  SORT  utility.  Most  SAIR/DAIR  quick 
reports  can  be  derived  directly  from  the  mini  file  information.  A 
SAIRSORT  program  is  provided  to  permit  mini  file  records  to  be  sorted  on 
any  desired  sequence  of  mini  file  elements.  The  output  is  a  simple  AOS 
sequential  file  which  can  be  input  to  an  RPG  program  hardcopy  printing 
or  tape  output. 

The  interactive  data  base  maintenance  software  automatically  main¬ 
tains  a  transaction  log  of  all  valid  element  additions,  deletions,  and 
modifications  to  the  AAFIF  file.  Similarly  element  updates  having 
significance  to  the  ASSOTW  report  are  recorded  in  an  ASSOTW  log  file. 

The  transaction  log  is  actually  two  files  (1)  for  fixed  elements  and 
(2)  for  variable  text  fields.  The  transaction  log  has  many  purposes 
including: 

a.  primary  input  to  the  AFFUPDT  program  which 
generates  the  DIA  transaction  tapes; 

b.  provides  a  trigger  for  generation  of  the 
analyst's  positive  feedback  reports; 

c.  transactions  are  inputs  to  special  software 

for  updating  the  Minifile  and  Card  Image  File;  and 
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d.  transaction  log  provides  backup  in  the  event 
the  data  base  files  are  destroyed  and  must  be 
restored  from  earlier  versions.  A  data  base 
recovery  program  which  merges  the  transaction 
log  back  to  a  particular  point  in  time  equal 
to  the  last  good  version  of  the  saved  data  base 
is  provided  for  this  purpose. 

A  major  hardware  integration  milestone  was  achieved  with  the 
successful  checkout  of  the  remote  communications  link  between  the  M-600 
facility  in  Building  3  and  the  10  terminals  in  the  secured  vault  in 
Building  4.  During  the  development  effort  and  throughput  of  the  T&E 
period  the  high  speed  (56K  bps)  link  would  intermittently  go  out  of 
synchronization.  The  problem  was  aggravated  by  a  defect  in  the  terminal 
communications  firmware.  The  Datagraphix-132£  PROM  memories  were  sub¬ 
sequently  upgraded  by  the  vendor  and  the  loss  of  synchronization  occurs 
very  infrequently.  The  KG-34  Encrypt/decrypt  equipment  has  no  diagnostic 
panel  to  assist  the  isolation  of  the  troublesome  fault.  Lack  of  filtered 
clean  facility  power  in  Building  4  may  be  part  of  the  problem.  The 
line  synchronization  can  easily  be  restored  in  minutes  and  fortunately  the 
data  base  is  not  violated  when  communications  are  cut  off.  However,  the 
annoyance  can  lead  to  frustration  on  the  part  of  the  AIS  users  because  they 
are  required  to  log-on  again  before  resuming  their  data  base  maintenance. 

In  summary,  the  Air  Facilities  subsystem  provides  DMAAC/AD  with  a 
powerful  on-line  data  base  management  capability  with  a  wealth  of  soft¬ 
ware  support  tools  to  develop  AAFIF  applications  programs  and  to  provide 
the  necessary  capacity  for  meeting  changing  future  requirements. 


5.2.4  AAIPS  Cartographic  Electron  Beam  Recorder 

The  AAIPS  EBR  which  was  developed  under  subcontract  to  Synectics 
by  Image  Graphics,  Inc.  achieved  the  performance  expectations  as  specified 
in  the  Acceptance  Inspection  and  Test  Procedures  and  which  were  verified 
by  acceptance  testing  during  Phase  I  effort.  As  such  the  EBR  has  proven 
to  be  quite  capable  of  outputting  high  quality  Flight  Information  Products 
for  the  AAIPS  automated  production  environment.  The  EBR  recording 
versatility  permits  all  of  the  AAIPS  printed  documents  (including  the 
ASSOTW  report)  to  be  generated  in  a  cost-effective  manner. 

The  EBR  product  quality  test  and  evaluation  results  were  less  than 
the  quality  levels  inherent  in  the  film,  the  software,  EBR,  and  associated 
AAIPS  hardware.  However,  establishment  of  optimal  film  processing 
standards  which  include  correct  size  film  processor  units,  film  develop¬ 
ment  chemistry  recommended  by  KODAK,  proper  film  orientation  during  the 
film  processing,  and  exercise  of  EBR  film  quality  safeguards  (including  the 
Neutral  Test  Package)  should  alleviate  the  film  quality  debasements. 

These  discrepancies  were  definitized  in  the  AAIPS  Final  Test  Report, 

Volume  V,  Test  and  Evaluation. 


The  AAIPS  EBR  recording  throughput  capability  as  applied  to  the 
worst-case  workload  proved  to  be  marginally  acceptable.  The  projected 
EBR  utilization  throughout  the  28-day  cycle  would  be  77%  of  full  capacity. 
This  workload  included  the  recording  of  all  FLIP  products  for  both  Charting 
and  Publishing  subsystems  and  the  ASSOTW  production  for  the  worst-case  AIRAC 
cycle.  The  high  utilization  of  the  EBR  is  based  on  the  recommended  strategy 
of  reducing  the  backlog  of  EBR  recording  on  the  information  cutoff  date 
by  performing  a  full  non-archival  recording  run  on  all  FLIP  products 
earlier  in  the  cycle.  The  price  of  leveling  the  workload  backlog  is  an 
overall  greater  amount  of  EBR  recording.  However,  in  order  to  ensure 
all  FLIP  products  can  be  printed  and  distributed  by  their  effective  dates, 
leveling  the  burden  on  the  EBR  is  mandatory. 

5.3  AAIPS  PERFORMANCE 


The  Automated  Air  Information  Production  System  (AAIPS)  as  developed, 
implemented,  and  tested  at  the  Defense  Mapping  Agency  Aerospace  Center 
(DMAAC)  Aeronautical  Information  Department  (AD)  meets  or  exceeds  the 
performance  requirements  for  the  automated  production  of  Flight  Information 
Products  and  Maintenance  and  Exploitation  of  the  AAFIF  file. 

In  assessing  all  of  the  results  of  the  AAIPS  system  it  is  apparent 
that  the  technology  required  to  successfully  complete  the  effort  covers 
a  wide  spectrum  within  the  DMA  R&D  program.  The  AAIPS  stands  as  a 
movement  attesting  to  the  wisdom  of  compiling  the  management  and  tech¬ 
nical  expertise  fostered  within  the  R&D  environment  with  outstanding 
cooperation  and  support  from  the  end  user  agency  to  successfully  develop 
a  cost-effective  and  highly  responsive  production  system. 


5.4  RECOMMENDATIONS 


The  recommendations  identified  herein  are  essentially  short-term  in 
nature  and  are  primarily  focused  on  rectifying  certain  encumbrances  within 
the  current  AAIPS  operational  environment  to  ensure  complete  and  satis¬ 
factory  transition  of  the  AAIPS  into  successful  full  production  operation. 

The  realities  of  the  environment  surrounding  the  AAIPS  is  that 
change  is  inevitable.  A  perpetual  assessment  of  the  effectiveness  of 
operational  procedures,  personnel  utilization,  production  management, 
quality  control,  and  system  maintenance  is  an  inherent  responsibility  of 
management.  As  with  any  system  employing  state  of  the  art  technology 
in  hardware  and  software  it  is  imperative  that  the  user  be  alert  to  take 
advantage  of  new  technology  when  it  becomes  expedient  to  do  so.  It  is 
incumbent  upon  the  user  to  master  the  technology  available  to  achieve 


optimal  performance  and  to  recognize  deficiencies  requiring  remedial 
correction  or  replacement. 


The  recommendations  perceived  by  Synectics  are  based  on  a  relatively 
limited  view  of  the  operational  AAIPS  as  provided  by  the  test  and  eval¬ 
uation  exercises.  For  this  reason  the  list  below  is  by  no  means  complete 

a.  Comprehensive  FLIP  Proofing  and  Quality  Control 

The  Phase  II  T&E  demonstrated  the  need  for  a  quality 
control  procedure  to  be  established  and  enforced  by 
production  management  during  the  capture  and  revision 
of  the  FLIP  product  data  bases.  Although  the  error 
suppression  mechanisms  such  as  proof  listings  and 
CRT  hardcopies  are  barely  adequate  the  evidence  of 
the  T&E  suggests  they  were  never  employed. 

In  the  case  of  the  Publishing  subsystem  neither  the 
CRT  softcopy  display  nor  the  upper/lower  case  printer 
can  accurately  portray  the  layout  conditions,  font 
style  and  size,  justification,  setwidth  or  variable 
loading  of  the  text  products.  Proofing  is  limited 
to  ascertaining  the  correctness  of  the  textual  con¬ 
tent  not  the  esthetic  graphics  art  quality  condition. 

The  enroute  charts  of  the  Charting  subsystem  defy 
adequate  proofing  by  means  of  the  small  format 
TEKTRONIX  hardcopy  unit.  Full  scale  proofing  is 
unavailable  in  the  AAIPS  as  it  is  presently  con¬ 
figured. 

Synectics  recommends  that  a  large  format  proofing 
plotter  of  the  electrostatic  variety  be  acquired  to 
support  the  proofing  requirement  for  the  FLIP  products. 

This  capability,  in  concert  with  effective  quality 
control  practices,  will  minimize  operator-induced 
data  errors  from  contaminating  the  EBR  film  masters 
by  permitting  early  detection  and  corrective  action 
prior  to  EBR  preparation. 

b.  Achieve  Film  Quality  Procedures 

A  competent  organization  should  be  engaged  to  design 
procedures  for  all  film  aspects  in  the  AAIPS  production 
train.  It  is  obvious  that  to  avoid  latent  image  decay 
(which  is  an  oxidation  effect)  on  unprocessed  recorded 
imagery  the  SO-219  film  must  be  processed  as  soon  as 
possible  after  recording.  The  film  density  diminishes 
most  rapidly  in  the  first  four  hours  after  recording. 

Therefore,  on-site  film  processing  is  recommended. 


Exploit  the  Continous-Tone  Properties  of  SP-219  Film 

Kodak  Direct  Electron  Recording  Film,  SO-219  is  a 
continuous-tone  film  emulsion  Estar  base.  It  was 
specified  to  record  the  wide  range  of  density  levels 
required  to  achieve  the  various  half  tones  in  the 
end  paper  products.  The  recording  of  high  contrast 
(maximum  density)  images  which  is  the  present  method 
employed  is  compatible  with  the  film  processing 
procedures  in  the  DMAAC  photo  laboratories.  However, 
the  generation  of  an  EBR  film  positive  for  each  color/' 
half-tone  screen  separation  uses  a  maximum  of  film  and 
increases  the  number  of  film  processing/compositing 
steps.  Synectics  recommends  that  the  original  EBR 
film  post-processing  strategy  as  specified  in  the 
AAIPS  Design  Plan  be  pursued.  The  approach  suggested 
that  continuous-tone  positives  be  recorded  by  combining 
certain  combinations  of  half-tones  on  the  same  image. 
Each  half-tone  would  be  associated  with  a  particular 
density  level  (gray  shade).  Preliminary  experimentation 
during  the  pilot  phase  showed  promising  results  by 
recording  100%  features  and  120  line  pairs/millimeter 
half-tone  screened  features  together  while  recording 
the  200  line  pair/millimeter  half-tone  screened 
features  on  a  separate  image.  The  resultant  enlarged 
continuous- tone  negatives  would  be  screened  by 
either  a  120  1pm  or  200  1pm  soft  dot  screen 
depending  on  the  separation  during  the  compositing 
stage.  Experimentation  with  the  time  of  exposure 
while  screening  to  achieve  the  optimal  compromise 
would  be  necessary.  The  large  cost-savings  potential 
and  time  reduction  that  this  approach  promises  are 
compelling  reasons  for  renewed  experimentation. 

Acquire  an  Additional  EBR  to  Ensure  Adequate  Backup 

Overall  mission  success  of  the  automated  production 
of  Flight  Information  Products  depends  heavily  on 
the  reliability  of  the  EBR.  It  is  particularly 
critical  that  the  EBR  be  available  for  use  at  all 
times  during  the  last  week  of  each  28-day  cycle  and 
three  days  following  the  information  cut-off  date. 
Despite  projecting  an  acceptable  margin  of  EBR 
throughput  capability  against  the  worst-case 
production  workload  considering  a  90%  sysrem 
availability,  there  is  a  high  degree  of  risk 
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associated  with  a  single  EBR  operation.  No  matter 
how  redundant  the  spare  parts  inventory  is  and  how 
competent  and  responsive  the  maintenance  support 
staff  is,  there  are  undoubtedly  certain  circumstances 
of  hardware  failure  that  could  cause  unacceptable 
downtimes  contributing  to  the  missing  of  a  handoff 
date  to  a  publishing  contractor.  Should  the  EBR  fail 
critically  during  the  post-cutoff  period,  there  would 
be  a  high  probability  that  the  FLIP  products  could  not 
meet  their  effective  dates  of  issue.  For  this  reason 
the  acquisition  of  a  duplicate  AAIPS  Cartographic  EBR 
system  is  recommended.  IGI  suggestions  for  incorpor¬ 
ating  an  improved  beam  deflection  yoke,  higher  capacity 
vacuum  system,  and  an  all-digital  Symbol/Vector  Genera¬ 
tor  should  be  seriously  considered. 

e .  Record  Matrix  of  Microimages  for  Text  Products 

The  pure  text  publications  are  recorded  at  100% 
density  and  are  excellent  candidates  for  micro¬ 
image  recording  (i.e.,  16  or  32  up).  The  payoff 
would  be  in  film  savings  and  less  film  handling  in 
subsequent  film  processing  steps.  Investigations 
should  also  be  conducted  to  determine  the  feasibility 
of  microimage  recording  for  graphic  char.tlets  including 
IAP's,  SID's,  and  airfield  diagrams. 

f .  Assure  Clean  Facility  Power 


At  various  times  throughout  the  contract 
performance  period  adverse  power  conditions  were 
experienced  in  the  AAIPS  facility.  A  competent 
organization  should  be  engaged  to  study  the  problem 
and  recommend  corrective  action  to  assure  the  avail¬ 
ability  of  clean  power  at  all  times.  The  study 
should  include  the  synchronous  communications  dif¬ 
ficulties  experienced  with  the  remote  communications 
link  connected  to  the  data  terminal  equipment  in 
Building  4 . 

g.  Enhance  Subsystem  Applications  Software 

A  number  of  software  improvements  have  been  noted 
in  the  conclusions  section  of  this  report.  These 
items  address  obvious  areas  for  improvement  as 
experienced  and  reported  to  Synectics  by  ADA 
personnel  tasked  with  the  responsibility  for 
operating  and  maintaining  the  subsystem.  Without 
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doubt  as  ADA  users  become  much  more  familiar 
with  the  subsystems  this  list  will  grow.  At 
the  same  time,  internal  AD  needs  and  external 
product  requirements  will  add  their  toll  to 
the  yrowinq  list.  The  greatest  challenge  of 
the  AAIPS  as  the  system  transitions  into  full 
production  lies  within  the  capacity  of  the  ADA 
system  analysis  and  programming  staff  to 
manage  change.  With  good  software  engineering 
discipline,  realistic  support  from  management, 
and  reasonable  requirements  and  time  frames, 
productive  software  improvements  can  be 
accomplished.  Without  careful  analysis  of 
proposed  software  changes  and  their  impact 
on  the  overall  subsystem  the  AAIPS  subsystems 
performance  could  deteriorate  to  a  point  where 
capabilities  would  be  rendered  useless.  This  is 
always  the  risk  when  an  extremely  complex 
software  system  and  the  responsibility  for 
maintaining  it  is  transferred  from  the 
developer  to  the  end  user. 


5.4.1  AAIPS  Subsystem  Hardware  Reconfiguration 

Throughout  the  contract  performance  period  the  development  team 
has  worked  steadfastly  toward  implementing  the  system  as  it  was 
originally  specified  in  the  design  plan  during  the  early  stages  of 
Phase  I.  Three  years  have  passed  since  the  original  design  was  prepared 
and  in  that  time  technology  has  advanced  and  our  collective  understanding 
of  the  AAIPS  operational  requirement  has  been  refined.  Realizing  that 
the  processing  workload  is  not  shared  equally  across  all  three  subsystems, 
some  hardware  reconfiguration  should  be  considered.  The  concepts  pre¬ 
sented  here  involve  a  minimal  cost  solution  while  maximizing  the  legacy 
of  the  considerable  software  investment  in  the  current  AAIPS.  The  benefits 
of  the  reconfiguration  presented  below  are: 

a.  Improved  Charting  Subsystem  Throughput  and 
Reliability; 

b.  Publishing  Subsystem  Backup; 

c.  Improved  Air  Facilities  Subsystem  Throughput 
and  Backup;  and 


d.  Improved  Proofing  of  FLIP  Products. 


5.4. 1.1  Physical  Integration  of  the  Charting  and  Publishing  Subsystems 


The  proposed  Charting  Subsystem  reconfiguration  would  involve  a 
distributed  arcnitecture  with  a  centralized  host;  each  workstation 
would  be  a  distinct  processing  entity  independent  of  the  other  workstations 
and  the  work.  Each  work  station  would  be  supported  by  a  satellite  processor 
connected  in  a  point-to-point  mode  with  the  ECLIPSE  S-230  host  processor 
(Reference  Figure  5-1) .  This  distributed  architecture  offloads  the  burden 
of  the  interactive  station  software  from  the  S-230  processor  to  the 
station  satellite  processor  thereby  freeing  the  S-230  for  other  processing. 
Each  satellite  processor  has  its  own  local  mass  storage  for  operational 
software  and  temporary  drawing  files,  symbol  files,  etc.  Each  station 
would  normally  operate  independently  of  the  host  thus  providing  greater 
system  reliability  in  the  event  of  a  host  processor  failure. 

Synchronous  communications  lines  between  the  host  and  each  satellite 
would  be  used  for  down  loading  temporary  drawing  files  to  the  stations  or 
reforming  revised  drawing  files  to  the  host  master  data  base.  Backup  for 
the  communications  link  is  provided  by  the  presence  of  a  comparable 
removable  disk  storage  unit  on  the  host. 

The  architecture  permits  ease  of  modular  expansion.  Additional 
satellite  stations  can  be  incorporated  with  minimal  extra  burden  on  the 
host  processor. 

Each  S-230  host  processor  would  be  upgraded  with  synchronous  line 
multiplexors  and  communications  chassis.  The  memory  of  the  host  processor 
would  be  expanded  to  256K  words  to  permit  operation  of  the  Data  General 
Advanced  Operating  System  (AOS) .  A  10-megabyte  disk  cartridge  subsystem 
consisting  of  one  removeable  5-megabyte  cartridge  and  one  5-megabyte  fixed 
cartridge  would  be  provided  on  the  host.  This  would  provide  an  alternate 
means  for  transmitting  data  files  to/from  the  host/satellite  processors. 

An  additional  Datagraphix  CRT  with  the  Publishing  character  set  and  two 
INFORMER  V301  monitors  and  4-line  asynchronous  line  multiplexers  would  be 
incorporated  on  the  host  processor. 

Presently  the  AAIPS  has  4  Datagraphixs  terminals  processing  the 
Publishing  character  set  (i.e.,  2  DX-132B's  on  Charting  and  2  DX-132A's 
on  Publishing) .  These  terminals  could  be  reconfigured  on  the  two  Charting 
Subsystem  host  processors  for  minimal  cost.  Two  additional  V301  monitors 
would  be  purchased. 

The  host  processor  would  be  capable  of  operating  under  either  AOS  or 
RDOS .  For  example,  under  R DOS  all  of  the  Publishing  software  and  the 
Charting  post-processing  software  could  be  processed  with  no  software 
conversion  necessary.  Under  AOS  the  binary  synchronous  communications 
(BSC)  device  drivers  would  perform  the  host/satellite  communications. 

AOS  also  provides  an  excellent  software  development  environment  for  new 
applications  programming.  Eventually,  the  portions  of  the  Publishing  and 


Charting  software  could  be  converted  to  AOS  but  this  could  be  done 
gradually. 

A  large  format  electrostatic  printer  plotter  with  a  microprocessor 
controller  and  integral  vector-to-raster  conversion  capability  would  be 
connected  by  a  communications  line  to  each  S-230  host  processor.  Proofing 
of  FLIP  graphics  and  text  products  would  be  completely  accommodated. 

Each  satellite  station  would  be  supported  by  a  Data  General  NOVA  4/S 
processor  with  32 K  words  of  memory  and  10  megabyte  disk  cartridge  sub¬ 
system.  A  synchronous  line  multiplexor  would  be  incorporated  to  permit 
communications  to  the  host.  Each  NOVA  4/S  would  support  a  single  work¬ 
station  consisting  of  current  AAIPS  Charting  Subsystem  hardware  including 
a  Dasher  terminal  printer.  Data  Automation  digitizer  and  Tektronix  4014-1 
CRT.  The  NOVA  4/S  supports  RDOS  and  the  interactive  Charting  Subsystem 
software  can  be  directly  transported  to  the  NOVA  4/S  with  no  software 
conversion  required.  The  RDOS  Communications  Access  Manager  (CAM) 
supports  binary  synchronous  communications  (BSC)  to  permit  communications 
to  the  host  processor.  Synectics  recommends  that  at  least  one  work¬ 
station  be  provided  with  a  Tektronix  GMA  1o2a  CRT.  The  GMA  CRT  would 
have  storage  and  refresh  graphics  capability,  highspeed  vector/character 
generator,  and  an  interface  to  the  4631  hardcopy  unit.  The  GMA  CRT  would 
be  interfaced  to  the  NOVA  4/S  via  a  highspeed  DMA  interface  permitting 
data  transfer  rates  of  2  megabytes  per  second.  The  workstation  having 
the  GMA  CRT  would  be  used  primarily  for  revision  of  enroute  charts  where 
the  need  for  fast  display  throughput  is  critical. 

The  proposed  reconfiguration  of  the  Charting  and  Publishing  subsystems 
has  many  benefits  as  summarized  below. 

a.  The  Publishing  Subsystem  is  completely  supported 
by  two  processors  (i.e.,  S-230  hosts).  Thus 
100%  backup  of  the  Publishing  Subsystem  is 
accomplished  with  minimal  hardware  and  virtually 
no  extra  software  cost.  The  ECLIPSE  C-330 
processor  would  also  be  completely  available 
for  other  processing. 

b.  The  complete  independence  of  each  satellite 
workstation  assures  greater  system  reliability. 

Further  schedule  conflicts  between  interactive 
processing  versus  EBR  post-processing  is 
eliminated.  Three-shift  per  day  workstation 
operation  would  be  permitted.  Thus  greater 
revision  throughput  is  possible. 

c.  The  S-230  host  processors  freed  from  supporting 
the  workstations  on  a  real-time  basis  have  more 
time  available  for  other  processing.  Some  of  this 
extra  time  will  be  for  supporting  the  Publishing 


requirement.  The  remaining  time  will  be 
available  for  accomplishing  the  FLIP  EBR 
post-processing  workload,  which  can  be  per¬ 
formed  concurrent  with  the  satellite  workstation 
processing  with  no  interface. 

d.  Additional  satellite  workstations  can  easily 
be  incorporated  with  min.mal  burden  to  the 
host  processors.  Thus  system  expansion  to 
accommodate  growth  of  the  FLIP  production 

or  to  add  extra  stations  to  reduce  operations 
to  a  two-shift  or  single-shift  basis  can 
be  accomplished  with  minimal  input  on  the 
current  architecture. 

e.  The  merging  of  text  and  graphics  for  EBR 
preparation  would  no  longer  require  the 
tape  handling  required  in  the  current 
system.  All  Publishing  and  Charting  subsystem 
product  data  bases  would  co-reside  on  the  same 
miss  storage  medium. 

The  concept  proposed  above  is  not  just  a  hypothetical  approach. 
Synectics  is  developing  a  system  at  RADC  for  the  DMAHTC  with  an  almost - 
identical  configuration.  The  Advanced  Cartographic  Data  Digitizing 
System  ( ACDDS )  will  be  in  operational  production  in  1981.  The  ACDDS 
is  an  advanced  architecture  version  of  the  Lineal  Input  System 
currently  in  operation  at  both  DMA  centers .  The  special  hardware  inter¬ 
face  between  the  NOVA  4/S  and  the  GMA  102A  CRT  and  the  graphic  CRT 
device  handler  software  is  being  developed  under  the  ACDDS  contract. 
Further,  the  binary  synchronous  communications  protocol  software  to  support 
the  point-to-point  communications  between  the  host  and  satellite  processors 
will  be  available  under  the  ACDDS  contract. 

The  ACDDS  also  features  state-of-the-art  voice  recognition  and 
scanning  cursor  technology  which  would  also  be  of  considerable  interest 
to  DMAAC/AD.  Some  of  the  ACDDS  NOVA  4/S  processors  will  be  equipped  with 
a  microprocessor-based  electronic  speech  recognition  system.  The 
Threshold  Technology  500  terminal  has  a  64  word  vocabulary  which  can  be 
increased  by  expanding  memory.  The  speech  processor  provides  visual 
feedback  of  each  spoken  word  that  is  recognized  by  means  of  a  16  alpha¬ 
numeric  character  LED  display.  The  voice  entry  capability  allows  the 
operator  to  enter  feature  descriptions  and  command  data  without  inter¬ 
rupting  vision  or  concentration  by  ke>  board  entry . 

Other  satellite  stations  will  have  direct  plug-in  microprocessor- 
based  scanning  cursors.  The  ACDDS  digitizer  table  vendor,  ALTER 
Corporation, is  manufacturing  a  scanning  cursor  comprised  of  a  100  X  100 
photo  diode  matrix  and  angle  digitizer.  This  cursor  will  allow  trace 
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digiting  rates  three  times  greater  than  conventional  cursor;  it  will  alsO 
cause  less  fatigue  on  the  part  of  the  operator  because  the  tracing  is 
computer- ass is ted  and  much  less  tedious  than  with  conventional  methods. 

The  Aeronautical  Department  is'  well  advised  to  track  the  development 
of  this  new  technology  and  to  take  advantage  of  it  when  it  becomes 
available. 

5. 4. 1.2  Upgrading  the  Data  General  ECLIPSE  C-330  Processor  to  Share 
the  Air  Facilities  Subsystem  Output  Processing  Workload 

The  physical  hardware  integration  of  the  Charting  and  Publishing 
subsystems  would  free  the  C-330  processor  for  other  processing.  One 
possible  use  for  this  additional  processor  would  be  to  offload  some  of 
the  output  processing  from  the  Air  Facilities  Subsystem.  Performing 
tape  verification  and  copying  would  be  one  useful  application.  Another 
significant  tactic  would  be  to  transfer  the  Card  Image  File  and  its 
associated  processing  to  the  C-330.  Further  there  could  be  considerable 
advantages  to  having  dual  AAFIF  data  bases.  The  AAFIF  file  residing  in 
the  M-600  would  be  maintained  interactively  on  a  daily  basis  as  per 
usual.  A  second  AAFIF  file  would  reside  on  the  C-330  and  would  be 
updated  daily  via  the  transaction  log  residing  on  the  M-600  after  the 
AIS  transactions  were  completed.  Both  data  bases  would  be  content 
equivalent  and  both  processors  could  be  used  to  generate  the  AAFIF  tape 
and  hardcopy  production. 

The  C-330  processor,  unlike  the  M-600  would  be  capable  of  operating 
under  both  the  RDOS  and  AOS  operating  systems.  Experience  with  both 
the  RDOS  and  AOS  versions  of  the  INFOS  data  base  software  has  been 
that  indexed  sequential  access  method  (ISAM)  file  processing  throughput  is 
greater  under  the  RDOS  INFOS.  It  is  currently  believed  that  the  Card 
Image  File  tape  output  processing  (HTAPE  program)  could  realize  a  possible 
throughput  improvement  of  25  to  50  percent  under  RDOS.  Thus,  the  motiva¬ 
tion  to  provide  backup  for  the  AAFIF  output  processing  and  to  improve  the 
overall  throughput  of  the  Air  Facilities  subsystem  is  the  principle  reason 
for  upgrading  the  C-330  processor. 

The  hardware  reconfiguration  (Reference  Figure  5-2)  would  require 
a  memory  expansion  on  the  C-330  from  256K  bytes  to  512K  bytes,  which  is 
minimum  memory  requirement  for  AOS.  A  2M  byte  fixed  head  disk  for 
swapping  least  recently  used  memory  pages  is  also  recommended  to  facilitate 
the  AOS  multiprogramming  flexibility.  A  Dasher  terminal  printer  would 
also  be  required  by  AOS  for  the  system  monitor  console.  Since  the 
C-330  would  be  heavily  utilized  for  tape  copy  and  validation  processing, 
the  magnetic  tape  hardware  would  be  expanded.  A  dual  7-track  magnetic 
tape  drive  subsystem  should  be  acquired  to  permit  7-track  tape  duplication 
and  also  provide  a  measure  of  redundancy.  Similarly,  an  additional 
9-track  switch-selectable  (800/1600  bpi)  magnetic  tape  store  drive 
should  be  acquired  to  expand  the  9-track  capability  to  a  dual  drive 
subsystem.  Since  the  processor  may  support  a  maximum  of  two  tape 
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Figure  5-2.  ECLIPSE  C-330  Configuration  Expansion 


controllers  the  Wang  9-track  1600  bpi  tape  drive  and  controller  would 
necessarily  be  removed  from  the  C-330.  The  disk  sybsystem  of  the  C-330 
would  be  expanded  to  a  total  of  8-192M  byte  disk  drives.  Although  Data 
General  Corporation  now  has  a  30QM  byte  disk,  the  ability  to  transport 
disks  between  the  M-600  and  C-330  processors  would  not  be  possible  if  the 
large  capacity  drives  were  acquired,  since  the  Card  Image  File  would 
no  longer  be  resident  on  the  M-600,  four  disk  drives  and  a  disk  controller 
from  the  M-600  would  be  installed  on  the  C-330  processor.  Thus  only  3 
additional  192M  byte  disk  drives  would  need  to  be  acquired.  They  would 
be  installed  on  the  disk  controller  currently  supporting  the  single  disk 
drive  on  the  C-330.  A  burst  multiplexor  channel  (BMC)  is  also  recommended 
to  support  the  disk  controllers  and  to  permit  greater  disk  I/O  throughput. 

The  number  of  Datagraphix  132B  terminals  that  would  be  acquired 
depends  on  the  amount  of  programming  and  Air  Facilities  related  traffic 
expected  to  be  performed  on  the  C-330.  A  minimum  of  four  CRT's  is 
recommended.  A  4-line  asynchronous  line  multiplexor  that  is  currently 
available  on  the  C-330  could  support  a  total  of  4  CRT's  with  no  expansion 
to  the  current  communications  hardware  necessary.  An  alternative  con¬ 
sideration  would  be  to  configure  two  CRT's  as  foreground/background 
terminals  to  support  RDOS  in  addition  to  having  two  CRT's  connected  to 
the  asynchronous  line  multiplexor.  Selection  of  the  Datagraphix  terminals 
as  opposed  to  alternative  alphanumeric  CRT's  is  for  complete  compatability 
with  Air  Facilities  software.  The  c-330  configuration  would  be  capable 
of  supporting  the  interactive  data  base  maintenance  activity  to  a  limited 
degree  in  the  event  of  prolonged  down  time  in  the  M-600. 

5.4.2  Long  Term  Recommendations 

The  AAIPS  production  capability  will  mark  the  achievement  of  a  major 
milestone  in  the  automated  production  of  flight  information.  The  avail¬ 
ability  of  the  AAIPS  product  data  bases  will  stimulate  great  interest  on 
the  part  of  traditional  users  for  more  rapid  and  varied  access  to  the 
AAIPS  aeronautical  information.  The  Aeronautical  Information  Department, 
which  is  primarily  a  service  organization  for  DoD  flight  information 
users,  must  be  postured  to  anticipate  and  react  to  external  and  internal 
user  requirements  created  by  the  demand  for  new  and  additional  products. 
These  products  may  take  the  form  of  micrographics,  video  disks,  or  more 
traditional  paper  hardcopy.  There  will  also  be  an  unprecedented  demand 
for  both  textual  and  graphic  data  to  be  transmitted  in  digital  form  in 
a  near  real-time  response  to  user  requests.  For  these  reasons,  DMAAC/AD 
must  be  continually  prepared  to  assess  related  technology  and  to  be 
sensitive  to  new  technological  developments  as  well  as  be  able  to  identify 
potential  future  requirements. 

In  order  to  prepare  for  the  future,  Synectics  recommends  that  in 
parallel  with  a  review  of  future  requirements  an  AAIPS  impact  analysis  be 
performed.  The  areas  of  impact  that  would  be  most  heavily  effected  by 
future  requirements  levied  upon  the  AAIPS  environment  would  be  the  data 
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base  structures,  user  interfaces,  system  architecture,  and  product  generation 
capabilities .  The  impact  analysis  would  be  a  system-wide  logistic  approach 
in  order  that  recommendations  would  be  put  forth  reflecting  the  best  over¬ 
all  solutions  for  upgrading  the  AAIPS. 

The  definition  of  user  requirements  would  be  the  logical  starting 
point  for  this  analysis.  Old  and  potential  new  users  would  be  identified 
and  classified  according  to  their  particular  information  needs.  Possible 
user  requirements  impacting  on  the  AAIPS  might  include: 

a.  remote  on-line  access  to  each  of  the  AAIPS  subsystem 
data  bases; 

b.  integration  of  the  data  bases  to  support  increasing 
access  requirements; 

c.  electronic  transmission  of  AAFIF  products;  and 

d.  electronic  transmission  of  the  FLIP  textual  and 
graphic  products  for  remote  facsimile  hardcopy 
generation. 

New  and  different  product  generation  capabilities  would  also  be 
identified.  These  could  possibly  include  microforms  of  certain  AAIPS 
products  such  as  FLIP  terminal  procedure  (IAP’s  and  SID’s)  and  the  ASSOTW 
report.  Improvements  to  internal  product  generation  capabilities  may  also 
be  required  as  a  result  of  breakthroughs  in  related  technology  such  as 
laser  platemaking.  It  is  conceivable  that  direct  laser  recording  of 
final  press  plates  by  digital  input  of  AAIPS  product  file  information  to 
a  laser  platemaking  subsystem  could  some  day  alleviate  the  need  for  the 
EBR.  Similarly,  archival  recording  of  AAIPS  products  by  means  of  optical 
disk  mass  storage  technology  could  become  a  requirement  for  those  users 
with  playback  and  softcopy  display  capabilities.  Remote  transmission 
of  AAIPS  information  for  airborne  CRT  display  systems  is  another  example 
of  a  long  range  requirement  that  would  dramatically  impact  the  AAIPS 
environment . 

The  availability  of  the  varied  AAIPS  flight  information  in  manipulable 
digital  form  will  undoubtedly  beget  an  unprecedented  demand  for  new 
products  in  digital  and  multi-media  formats.  As  user  information 
requirements  expand,  DMAAC/AD  will  need  to  identify  and  evaluate  new  and 
applicable  sources  of  information  which,  too,  may  be  readily  available 
in  digital  form  for  direct  input  into  the  AAIPS. 

As  these  requirements  surface,  DMAAC/AD  must  be  prepared  to  assess 
their  impact  on  the  AAIPS  and  determine  how  best  to  satisfy  them  within 
the  framework  of  future  system  architecture,  hardware/software  technology, 
and  data  base  holdings.  Only  then  with  a  solid  implementation  plan  will 
enhancements  be  smoothly  integrated  into  the  AAIPS  production  environment 
and  will  DMAAC/AD  be  able  to  confidently  manage  the  changing  future. 
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Rome  Air  Development  Center 

PA VC  plans  and  executes  research,  development,  test  and 
Selected  acquisition  programs  In  support  of  Command,  Control 
Communications  and  Intelligence  (C3IJ  activities.  Technical 
and  engineering  support  within  areas  of  technical  competence 
Is  provided  to  ESP  Program  Offices  IPOs)  and  other  ESP 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur¬ 
veillance  o&  ground  and  aerospace  objects.  Intelligence  data 
collection  arid  handling.  Information  system  technology. 
Ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


